TS06Access and indexing

Is private content actually protected?

Prepare a useful access check for your technical team.

Prepare my access test

In the app: Access-test preparation
You provide: Private URL and authorized roles
Allow for: Reading and confirmation

Prepare my access test

Understand

Private content. Controlled access.

Prepare a useful access check for your technical team.

TSEP protocol criterion

TSEP separates the protection plan from evidence of access actually being denied. A non-indexed URL is not proof of confidentiality.

The rules and limits of this check are detailed at the bottom of this guide.

Check

Every role. Every access.

In TSEP Control

A copyable, downloadable test plan. No real-access verdict: the current engine only qualifies synthetic traces.

Your contribution

A private URL, allowed users, content to protect and expected denial.

With your own tools

Using an authorized environment and accounts, check access while signed out and with each planned role. Check files and API responses too, retaining evidence with secrets removed.

What this result covers

This workflow prepares a test: no anonymous request is sent and no real access is evidenced. Robots.txt or noindex do not protect private content.

Act

The server decides. Content stays private.

Enforce access denial on the server, then have every unauthorized role tested.

Recheck

Permissions change. Retest access.

Repeat the workflow with the same scope after correction. Date the new observation and retain earlier evidence.

Your reference points

To go further.

Statuses, sources and method.

Understand the statusesC · NC · NT · NA

The same legend in guides, analysis and demo. Each status depends on the control’s evidence and rules.

C · Verified: The criterion is met within the assessed scope. Keep dated evidence for the next comparison.
NC · To correct: Enforce access denial on the server, then have every unauthorized role tested.
NT · Not established: Evidence or confirmations are insufficient to conclude. Supply what is missing; this status does not establish an SEO error.
NA · Not applicable: The control does not apply to the scope under its rules, with a retained justification. Missing evidence alone does not make it non-applicable.

Sources and references4 references

Detailed method and rules1 rule

Control method and criteria

Method
Before observations, supply intent.ts06_access and bind its fingerprint in configuration.ts06_access. Declare routes, synthetic canaries, fictional roles, exact route/role tests, and cold anonymous → synthetic authorized seed → anonymous replay triplets with the same cache label. Inspect supplied GETs without DNS resolution or network requests. Authentication redirects must remain on the same origin (scheme, host, effective port) and follow an explicit path allowlist. A 404 counts as denial only when the plan declares it for that route.

Acceptance criteria
Pass means only that all declared unauthorized route/role cells are complete, denied without a sensitive marker, and every supplied triplet follows the declared order without a replay leak; the control measures neither real identity nor a real cache. Any attributable response to an unauthorized role containing a canary fails, including detected encoded bodies or response headers. A 2xx representation delivered to an unauthorized role also fails.

Non-applicability
The whole control may be not applicable only with a complete, dated, reasoned synthetic inventory review declaring no sensitive route in scope; no contradictory test or triplet may then be present.

Detailed rules

TS06-A01 · Access denied in the supplied synthetic HTTP matrix

Protocol assessment mode : assisted, with supplied evidence and declarations. App availability is shown on the control card.

Scope
At least one sensitive route is explicitly declared in the synthetic scope.

Evidence
Configuration/intent/http records linked to the target, plan fingerprint, routes/roles/tests, raw GET exchanges with timestamps, canaries and labelled cache triplets.

Method
Compare the prior plan bound to configuration with a complete synthetic GET matrix by route and role. Detect markers in headers and bodies, preserve contradictions before validating duplicates/gaps, verify same-origin redirects and cold/authorized/replay sequences.

Acceptance criteria
Pass covers only the complete supplied synthetic matrix: no unauthorized response contains a canary, denial is established under the plan, and every cold → authorized seed → anonymous replay triplet is complete and ordered. An attributable leak or unauthorized 2xx representation yields fail.

When the result remains inconclusive
Missing/future/inconsistent plan, missing/duplicate cell, absent/ambiguous role header, cross-origin redirect, 206, 304 without retained representation, unsupported encoding, or incomplete triplet/attribution.

Non-applicability
No atomic exemption. Whole-control NA requires a complete, dated, reasoned inventory review linked to intent.

Assumptions
Fixtures are supplied, synthetic and unauthenticated. Role and cache labels prove neither identity nor a shared cache.

Limitations
No DNS, socket, live collection, real identity, authentication, cookies, real cache, TLS, JavaScript, path aliases, HEAD, or whole-site assessment. Canary detection covers only implemented encodings; other cases are inconclusive.

Rule version 0.2.0-rc.1 · Public protocol reference · Versioned source

Put it into practice

← Back to controls