What is CORS
- Define it quickly (1 sentence)
CORS, or Cross-Origin Resource Sharing, is a contract between browser and server that relaxes the browser’s Same-Origin Policy. - Explain why it exists (1–2 sentences)
By default, browsers block cross-origin requests for security. CORS lets the server explicitly define which origins, headers, methods, or credentials are allowed. - Explain mechanism (1 sentence)
For non-simple requests, like PUT or PATCH, the browser first sends a preflight OPTIONS request to check if the method is allowed before sending the actual request.
Why preflight only for put patch delete
Browsers categorize requests as simple or non-simple.
Simple requests, like GET or standard POST, are considered safe because they only read or add data and use standard headers.
Non-simple requests, such as PUT, PATCH, or DELETE, can modify or remove data,
so the browser first sends a preflight OPTIONS request to the server to check if it’s allowed
before sending the actual request.
What happens if you set Access-Control-Allow-Credentials: true? When should you use it, and what are the pitfalls
When Access-Control-Allow-Credentials is set to true,
the browser includes cookies or other credentials in cross-origin requests.
This allows the server to identify or authenticate the client.
However, it’s a security risk if the server sets the allowed origin to *,
because then any site could send requests with the user’s credentials, potentially exposing sensitive data.
So, you should use it only when you explicitly trust the requesting origin
Your React app on localhost:3000 is calling a .NET Core API on localhost:5000. You get a CORS error. How do you fix it?
Since my React app runs on localhost:3000 and the .NET Core API runs on localhost:5000, the browser sees them as different origins and blocks requests by default due to the Same-Origin Policy.
To fix this, I configure CORS on the server to allow the React app’s origin.
In .NET Core, I use builder.Services.AddCors() to define allowed origins, methods, and headers,
then call app.UseCors() before authentication middleware in the pipeline.
This way, the browser can send requests successfully.
Security risks of misconfigured CORS
CORS is enforced by the browser, so the server still responds normally even if CORS is misconfigured.
The main security risk is that a malicious site could read responses if the server allows any origin or credentials too broadly.
So, in production, you should only allow trusted origins, restrict methods, and carefully handle credentials to avoid exposing sensitive data
What’s the difference between Access-Control-Allow-Headers and Access-Control-Expose-Headers? When would you use them
Access-Control-Allow-Headers tells the browser which headers it is allowed to send in the request, especially custom headers.
Access-Control-Expose-Headers tells the browser which headers in the response can be accessed by JavaScript.
By default, only simple headers are visible, so you expose custom headers when the client needs them.
