Cross-Origin Resource Sharing
CORS is a browser HTTP safety rule. A server lists which other origins may read its replies. It can limit methods, headers, and credentials.
Another example
A dashboard on app.example.com calls api.example.net. The API checks preflight before authenticated writes and allows only the production origin.
Main parts
- 01Identity or input
- 02Policy or transformation
- 03Stored result and audit evidence
Use it when
Set CORS on the server or gateway when browser code must read another origin.
Do not use it when
Do not use wildcard origins with credentials or reflect unknown origins. CORS does not replace authentication or CSRF protection.
Name used in code
Origin / Access-Control-Allow-* / OPTIONS Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review CORS for this system while keeping data correct, secure, and easy to operate. User context: A dashboard on app.example.com calls api.example.net. The API checks preflight before authenticated writes and allows only the production origin. Technical concept or control: CORS. Why it fits: Set CORS on the server or gateway when browser code must read another origin. Do not use it when: Do not use wildcard origins with credentials or reflect unknown origins. CORS does not replace authentication or CSRF protection. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): The standard covers only the listed scope. It does not choose the visual style, product decision, or Vibulary example. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of CORS. Definition: CORS is a browser HTTP safety rule. A server lists which other origins may read its replies. It can limit methods, headers, and credentials. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.