Production engineering
Reveal answer and reasoning
A credentialed API should authenticate through a real configured mechanism, authorize the selected resource and separately expose responses to an explicit browser-origin policy. If cookies are ambient credentials, design CSRF protection as another control. Validate preflight method/header requirements and actual endpoint behavior independently, and test denied identity and denied sharing as different outcomes. The origin value must never substitute for a trusted user, tenant or capability claim.
Origin is request metadata, not a reliable person or tenant identifier. A nonbrowser client can supply it directly, and some cross-origin requests can reach a server even when a browser later hides the response from script. This fixture configures no authenticated business action or credentialed cross-origin cookie workflow. Allowing an origin does not make an otherwise unsafe operation safe, and denying sharing does not replace antiforgery checks where ambient credentials are used.
A production design must also decide credential handling, allowed methods, request headers, exposed response headers and resource-specific authorization without folding them into one Boolean.
The result should describe which sharing headers were emitted, what the public endpoint returned and whether any identity existed. It should not label a successful preflight an authenticated request or an absent allowance a blocked server-side effect. The portable set comparison verifies only its fixed policy data, while the external middleware demonstrates real header behavior. A senior explanation treats CORS, authentication, authorization and CSRF defenses as related but distinct mechanisms with separate evidence.
That model makes future credentialed changes reviewable without overstating the protection supplied by an origin allowlist or a fictional HTTPS string in a test header.
What a strong answer covers
- A credentialed API should authenticate through a real configured mechanism, authorize the selected resource and separately expose responses to an explicit browser-origin policy.
- Origin is request metadata, not a reliable person or tenant identifier.
- The result should describe which sharing headers were emitted, what the public endpoint returned and whether any identity existed.
Common pitfall
Origin is request metadata, not a reliable person or tenant identifier. A nonbrowser client can supply it directly, and some cross-origin requests can reach a server even when a browser later hides the response from script. This fixture configures no authenticated business action or credentialed cross-origin cookie workflow. Allowing an origin does not make an otherwise unsafe operation safe, and denying sharing does not replace antiforgery checks where ambient credentials are used. A production design must also decide credential handling, allowed methods, request headers, exposed response headers and resource-specific authorization without folding them into one Boolean.
Follow-up questions
- Why does permitting POST in CORS policy not mean /cors/data has a POST handler?
- Which CORS headers concern permission to send a request, and which concern script access to a response?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.