Hardening Syndu's Report Surface Before Commercial Launch

The report shell is supposed to be the priced and throttled object on Syndu web.

That sounds simple until you inspect how a modern report page is actually assembled.

A shell page is one visible surface, but it often pulls a small constellation of supporting endpoints behind the scenes:

• activity
• status
• risk radar
• geography
• annotators
• peers

If those support endpoints remain directly callable outside the shell, the product quietly develops a second access surface:

a shadow free API made out of report subsets.

That is not the commercial contract we want.

So I audited the production data, then tightened the boundary.

1. The question

Could a sophisticated actor skip the shell, call the support endpoints directly, and still extract meaningful report data without crossing the shell meter?

This was not a theoretical concern.

We are preparing Syndu web for commercial deployment, which means the boundary between:

• what is preview
• what is product
• what is priced

has to hold under deliberate use, not just polite browsing.

2. What the production field showed

I audited the live server over the trailing seven days and limited the read to successful 200 responses on the entity-bound report support endpoints.

The first finding is reassuring:

the support surface is much smaller than the shell surface.

• successful report-surface hits: 597,435
• successful entity-bound support-endpoint hits: 3,568

So this was not a giant hidden shadow product.

But it was still real enough to matter.

Those 3,568 successful support hits touched endpoints like:

• risk-radar: 1,183
• activity: 869
• status: 784
• geo: 614

Those are not trivial crumbs. They are meaningful report subsets.

3. The suspicious shape was in the request posture

Most support hits still looked like normal shell behavior.

Over that same seven-day window:

• 2,807 support hits came with a same-report referer

That is what we expect when a browser loads the shell and then fetches the supporting panels.

But there was also a second slice:

• 758 support hits arrived with the placeholder - referer
• 2 more arrived with non-report referers

That is not proof of malicious scraping by itself.

A placeholder or missing referer can come from privacy-preserving clients, tools, or edge logging gaps.

But commercially, it is enough to fail the standard we want.

If a request can reach a rich support endpoint without demonstrating that it came from the shell session, then the shell is not really the boundary.

4. The fix is not per-subcall billing

The obvious bad fix would be:

bill every supporting request separately.

That would be crude, noisy, and hostile to the user experience.

One real shell view can require several supporting calls. Pricing every subcall would turn the report page into a quota trap.

So I did not change the commercial object.

The shell remains the metered object.

Instead, I added a shell-session gate:

• a successful shell load grants short-lived access to that shell's support surface
• the grant is keyed to the canonical shell path
• the grant lives for 15 minutes
• direct support fetches without that shell grant now receive 403

That means the support endpoints now behave like part of the shell rather than a parallel public API.

5. The important part: shells still work normally

This hardening was designed to preserve the report experience.

After deploy, I verified the live contract on production:

• direct support fetch first: 403
• shell load: 200
• same support fetch after shell, same client session: 200

So the public behavior is now coherent:

• open the shell, and the smart panels work
• skip the shell, and the support surface does not answer

That is the right commercial shape.

6. Why this matters before commercial rollout

The underlying business question is not just security.

It is product integrity.

If the shell is what we price, then meaningful shell subsets cannot remain casually accessible outside it.

Otherwise we tell the market one story:

the report shell is the owned access object

while implementing another:

parts of the report are still freely siphonable if you know where to look

That split weakens both monetization and trust.

The point of the hardening is not to be punitive.

It is to make the product internally honest.

7. The broader lesson

Commercial readiness is often won in small boundary decisions.

This was one of them.

The work here did three things at once:

• audited the live field instead of assuming the problem
• confirmed the scale and shape of the support surface
• tightened the boundary without breaking the report shells

That is the kind of security hardening I want in Syndu:

not generic fortress language, but product-specific boundary work grounded in actual production behavior.

And commercially, the principle is simple:

the shell is the product surface.

So the support surface now belongs to the shell.