CSRF, CORS and CSP

Bounded outcome

This lesson separates three browser-security mechanisms that are frequently collapsed into one: CSRF protects a state-changing application flow from unwanted use of ambient authentication context; CORS controls whether a browser may expose a response across origins; and CSP constrains browser content loading/execution as defense in depth. The evidence artifact is Browser Request Boundary Control Record v1. It does not claim that the whole application is secure.

The entire exercise is synthetic and local. No real domain, account, credential, hostile payload, external target, or production runtime is required.

1. Different questions, different enforcement points

A useful security model starts by refusing to treat the three controls as synonyms.

1. CSRF asks whether an authenticated browser context can cause an unintended state change and which request/authentication assumptions require an anti-CSRF condition.
2. CORS asks whether a browser may share a response with script running under another origin.
3. CSP asks which browser content/resource sources or execution modes are permitted for a document.

These decisions are independent. CORS is not business authorization. CSP does not replace contextual output encoding, sanitization, or safe sinks. An anti-CSRF token is not a business authorization rule.

2. Origin is not site

An origin is scheme + host + port. Site is a distinct browser concept. Two synthetic sibling hosts may be marked as same-site while still being different origins. The lab deliberately uses fixture metadata for site relationships instead of pretending that a simple suffix heuristic implements the public suffix model.

Decision sequence:

• record origin relation;
• record credential context;
• record whether the operation changes state;
• evaluate CSRF policy;
• independently evaluate CORS response sharing;
• independently evaluate CSP resource policy.

3. CSRF boundary

The local model contains one synthetic preference-update route using ambient session-like credentials. A valid state change requires the declared trusted origin, business authorization, and the synthetic anti-CSRF signal. The positive path returns ALLOW_STATE_CHANGE.

Negative Evidence

Remove the synthetic anti-CSRF signal. The local model must return DENY_MISSING_CSRF. Change the origin to an untrusted synthetic origin and expect DENY_ORIGIN. These are defensive data mutations against a local fixture, not instructions for targeting an external service.

Do not treat CORS as the CSRF defense. A browser can send requests whose responses are not readable by the initiating script, so response-sharing denial does not prove that a state change was prevented.

4. CORS boundary: response sharing, not authorization

Within the frozen WHATWG boundary, CORS is modeled as an opt-in response-sharing protocol layered on HTTP. The fixture has a read-only status endpoint that may be shared with one declared partner origin and a separate state-changing preference operation with independent business authorization.

The record therefore separates cors_sharing_decision from business_authorization_observation. A local mutation may broaden the CORS allowlist; that can change response sharing while leaving authorization false. The learner must preserve that distinction.

Preflight boundary

A preflight observation belongs to the CORS protocol surface. It is not an authorization oracle. In the synthetic model, method/header combinations can require preflight, but the final business decision is still evaluated independently.

5. CSP boundary: browser defense in depth

CSP restricts browser content/resource sources. The synthetic policy allows approved local scripts and rejects a synthetic off-policy script in enforce mode. In report-only mode, the model records a violation without treating it as an enforced block.

Report-only and enforce are different observables and must remain separate in the evidence record. A CSP header is not proof that XSS has been eliminated. This lesson does not provide XSS payload construction or bypass techniques; the next lesson owns XSS, SQL injection, and input validation outcomes.

6. Browser Request Boundary Control Record v1

Every evidence row contains:

Facts, observations, and inference are different. CORS_SHARED is an observation. “Therefore the caller is authorized to modify preferences” is an invalid inference unless separate authorization evidence exists.

7. Baseline lab paths

The fixture includes:

• PREFERENCE_UPDATE_OK: synthetic POST to the app origin with ambient credentials, authorization=true, and the correct CSRF signal; expect ALLOW_STATE_CHANGE.
• PREFERENCE_UPDATE_MISSING_CSRF: same flow without the signal; expect DENY_MISSING_CSRF.
• STATUS_PARTNER_CORS: read-only GET from the allowed partner origin; expect response sharing=true.
• STATUS_UNKNOWN_CORS: GET from an origin outside the allowlist; expect sharing=false.
• LOCAL_SCRIPT_CSP: self-hosted script; expect CSP allow.
• REMOTE_SCRIPT_CSP_ENFORCE: synthetic off-policy script; expect block in enforce mode.
• REMOTE_SCRIPT_CSP_REPORT_ONLY: same resource in report-only mode; expect report without enforced block.

8. Failure modes and repair

Shortcut 1: “CORS prevents CSRF”

Repair by separating request/state-change evidence from response-sharing evidence. The CSRF negative probe must pass independently of CORS.

Shortcut 2: “Same-site means same-origin”

Repair by keeping the two classifications separate and using the declared fixture relationship.

Shortcut 3: “CSP means XSS is solved”

Repair by recording CSP only as defense in depth and leaving primary XSS defenses outside this lesson.

Shortcut 4: happy-path-only evidence

Repair by requiring one deliberate Negative Evidence observation for each owned mechanism.

9. Alternatives and trade-offs

The target is not “the largest number of security headers.” The smallest justified policy depends on the flow. CSRF control follows the authentication/request model. CORS should expose only the response-sharing surface required by the real use case, with authorization evaluated separately. CSP should match real resource needs while preserving the distinction between report-only and enforce.

A widened CORS allowlist changes the sharing surface. A stricter CSP can block legitimate resources. An anti-CSRF mechanism that does not match the architecture can add complexity without proving the intended invariant. Record trade-offs as evidence, not slogans.

10. Guided practice

1. Inspect the fixture.
2. Predict each flow result.
3. Run run_local_lab.py.
4. Compare output with the prediction.
5. Fill Browser Request Boundary Control Record v1 with observed facts.
6. Run the negative probes and retain the evidence.
7. Do not generalize local results into production-security claims.

11. Independent practice

Solve the changed context: a synthetic admin console and public status page have different authentication and cross-origin needs. Do not copy the first policy. Rebuild the control matrix from actual request boundaries.

Transfer

The transfer must independently identify state-changing flows, ambient credential contexts, response-sharing needs, CSP resource boundaries, and residual risk. The final decision cannot be supplied by the baseline example.

12. Assessment gates

• Retrieval: state the CSRF/CORS/CSP distinction and one Non-goal.
• Application: execute the bounded defensive case and capture evidence.
• Diagnosis: explain one deliberate failure probe.
• Decision: defend the smallest justified policy.
• Transfer: rebuild the matrix for a changed context.

Blocking failures include unsupported security claims, happy-path-only proof, or missing negative/transfer evidence.

Non-goals

• CORS is a complete CSRF defense.
• CSP replaces context-sensitive XSS defenses such as safe sinks, output encoding or sanitization.
• Same-site and same-origin are interchangeable security boundaries.
• A permissive cross-origin response policy is equivalent to authorization.

13. Freshness and sources

The source boundary is exactly three sources and is not expanded:

• OWASP-CSRF for current defensive CSRF guidance within the frozen claim boundary.
• WHATWG-FETCH-CORS for the current CORS protocol and response-sharing model.
• OWASP-CSP for CSP as client-side defense in depth.

The frozen snapshot was retrieved on 2026-09-02 and review_due is 2026-10-02. A voluntary primary-source check on 2026-09-16 remained inside the same three-source boundary and did not change the claims.

14. Evidence closure

The learner passes by defending one bounded decision with positive evidence, Negative Evidence, transfer evidence, and an explicit residual-risk statement. Green tests alone are not owner acceptance and do not prove production security. The record must distinguish what was observed, what was inferred, and what remains outside scope.

15. Lab safety boundary

All activity is local and synthetic. Network access is forbidden in the runtime. No real credential, real session, external target, exploit delivery, persistence, or covert access is permitted. If the task needs anything outside that boundary, stop the lab and return to scope review.