CORS configuration in Nginx - Commands & Configuration

Introduction

Web browsers block some requests from one website to another for security. CORS configuration tells the browser which websites are allowed to access resources on your server. This helps your web app work correctly when it talks to other servers.

When your frontend app on example.com needs to get data from api.example.org without errors

When you want to allow only specific websites to use your server's resources

When you want to prevent unknown websites from accessing your API

When you serve images or fonts that other websites can use safely

When you want to fix browser errors about blocked cross-site requests

Config File - nginx.conf

nginx.conf

server {
    listen 80;
    server_name example.com;

    location / {
        add_header 'Access-Control-Allow-Origin' 'https://allowed-site.com';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';

        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=UTF-8';
            add_header 'Content-Length' 0;
            return 204;
        }

        proxy_pass http://backend_server;
    }
}

This config sets up a server listening on port 80 for example.com.

The add_header lines tell browsers which origins, methods, and headers are allowed for cross-site requests.

The if block handles preflight OPTIONS requests by responding quickly with no content and caching instructions.

The proxy_pass sends requests to the backend server.

Commands

Check the nginx configuration file for syntax errors before applying it.

Terminal

sudo nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload nginx to apply the new CORS configuration without stopping the server.

Terminal

sudo systemctl reload nginx

Expected Output

No output (command runs silently)

Send a preflight OPTIONS request to check if CORS headers are correctly returned.

Terminal

curl -i -X OPTIONS https://example.com/ -H "Origin: https://allowed-site.com" -H "Access-Control-Request-Method: POST"

Expected Output

HTTP/1.1 204 No Content

Server: nginx

Date: Wed, 01 Jan 2025 12:00:00 GMT

Content-Type: text/plain; charset=UTF-8

Content-Length: 0

Access-Control-Allow-Origin: https://allowed-site.com

Access-Control-Allow-Methods: GET, POST, OPTIONS

Access-Control-Allow-Headers: Content-Type, Authorization

Access-Control-Max-Age: 1728000

→

-X OPTIONS - Send an OPTIONS request to test preflight CORS

→

-H "Origin: https://allowed-site.com" - Set the Origin header to simulate a request from allowed-site.com

Send a normal GET request with Origin header to verify CORS headers are present.

Terminal

curl -i https://example.com/ -H "Origin: https://allowed-site.com"

Expected Output

HTTP/1.1 200 OK

Server: nginx

Date: Wed, 01 Jan 2025 12:00:00 GMT

Content-Type: text/html

Content-Length: 612

Access-Control-Allow-Origin: https://allowed-site.com



<html>...</html>

→

-H "Origin: https://allowed-site.com" - Set the Origin header to simulate a request from allowed-site.com

Key Concept

If you remember nothing else from this pattern, remember: CORS headers must be sent by the server to tell browsers which websites can access its resources safely.

Common Mistakes

Not handling OPTIONS preflight requests in nginx

Browsers send OPTIONS requests before actual requests to check permissions; if not handled, requests fail.

Add a block in nginx config to respond to OPTIONS requests with proper CORS headers and status 204.

Setting Access-Control-Allow-Origin to '*' when credentials are needed

Browsers block requests with credentials if the origin is '*'.

Set Access-Control-Allow-Origin to the exact allowed domain instead of '*'.

Forgetting to reload nginx after changing config

Changes won't take effect until nginx reloads the config.

Run 'sudo systemctl reload nginx' after editing the config file.

Summary

Write nginx config to add CORS headers and handle OPTIONS preflight requests.

Test config syntax with 'nginx -t' before applying changes.

Reload nginx to apply new settings without downtime.

Use curl with OPTIONS and Origin headers to verify CORS behavior.

Practice

1. What is the main purpose of configuring CORS in an nginx server?

easy

A. To control which websites can access server resources

B. To improve server performance by caching

C. To encrypt data between client and server

D. To block all incoming traffic

Solution

1. Step 1: Understand CORS purpose

   CORS (Cross-Origin Resource Sharing) controls which external websites can request resources from your server.

2. Step 2: Identify correct purpose in options

   Only To control which websites can access server resources describes controlling access from other websites, which matches CORS functionality.

3. Final Answer:

   To control which websites can access server resources -> Option A

4. Quick Check:

   CORS controls access = D [OK]

Hint: Remember CORS controls cross-site resource sharing [OK]

Common Mistakes:

• Confusing CORS with encryption or caching
• Thinking CORS blocks all traffic
• Assuming CORS improves performance

2. Which of the following is the correct syntax to add a CORS header allowing all origins in an nginx configuration?

easy

A. add_header "Access-Control-Allow-Origin" "*";

B. add_header "Access-Control-Allow-Origin" *;

C. add_header Access-Control-Allow-Origin "*";

D. add_header Access-Control-Allow-Origin *;

Solution

1. Step 1: Understand nginx add_header syntax

   The header name does not require quotes unless it contains spaces or special characters. The value must be quoted if it is a string like "*".

2. Step 2: Identify correct quoting

   add_header Access-Control-Allow-Origin "*"; correctly quotes the value and does not quote the header name, which is the recommended syntax.

3. Final Answer:

   add_header Access-Control-Allow-Origin "*"; -> Option C

4. Quick Check:

   Proper quoting for header value only = B [OK]

Hint: Quote header value for safety in nginx, header name usually unquoted [OK]

Common Mistakes:

• Quoting header name unnecessarily
• Using * without quotes
• Misplacing semicolons

3. Given this nginx snippet inside a location block:

if ($request_method = 'OPTIONS') {
  add_header Access-Control-Allow-Origin "*";
  add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
  add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range";
  add_header Access-Control-Max-Age 1728000;
  add_header Content-Type "text/plain charset=UTF-8";
  add_header Content-Length 0;
  return 204;
}

What will be the HTTP status code returned for an OPTIONS request?

medium

A. 200

B. 204

C. 400

D. 500

Solution

1. Step 1: Analyze the if block for OPTIONS method

   The configuration checks if the request method is OPTIONS, then sets headers and returns status code 204.

2. Step 2: Identify the return status code

   The line return 204; explicitly sends HTTP status 204 (No Content) for OPTIONS requests.

3. Final Answer:

   204 -> Option B

4. Quick Check:

   OPTIONS returns 204 No Content = B [OK]

Hint: Look for return statement inside OPTIONS check [OK]

Common Mistakes:

• Assuming default 200 OK instead of 204
• Confusing OPTIONS with GET method
• Ignoring explicit return codes

4. You added this to your nginx config to allow CORS:

add_header Access-Control-Allow-Origin *;

But browsers still block cross-origin requests. What is the likely problem?

medium

A. The add_header directive is inside a location block without 'always' parameter

B. The header is missing quotes around '*', causing syntax error

C. nginx does not support CORS headers

D. You need to restart the browser to apply changes

Solution

1. Step 1: Understand add_header behavior in nginx

   By default, add_header only adds headers on successful (2xx) responses. For OPTIONS or error responses, headers may be missing unless 'always' is used.

2. Step 2: Identify missing 'always' parameter

   Without 'always', CORS headers may not be sent on OPTIONS or error responses, causing browser blocks.

3. Final Answer:

   The add_header directive is inside a location block without 'always' parameter -> Option A

4. Quick Check:

   Missing 'always' causes headers to be skipped = A [OK]

Hint: Use 'always' with add_header to send headers on all responses [OK]

Common Mistakes:

• Not using 'always' with add_header
• Assuming nginx lacks CORS support
• Forgetting to reload nginx after config changes

5. You want to configure nginx to allow CORS only from https://example.com and support preflight OPTIONS requests. Which configuration snippet correctly achieves this?

hard

A. add_header "Access-Control-Allow-Origin" "*";
add_header "Access-Control-Allow-Methods" "GET, POST";
return 204;

B. add_header Access-Control-Allow-Origin *;
if ($request_method = 'OPTIONS') {
return 200;
}

C. add_header "Access-Control-Allow-Origin" "https://example.com";
add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS";
add_header "Access-Control-Allow-Headers" "Content-Type";
return 200;

D. add_header "Access-Control-Allow-Origin" "https://example.com" always;
if ($request_method = 'OPTIONS') {
add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS" always;
add_header "Access-Control-Allow-Headers" "Content-Type" always;
add_header "Access-Control-Max-Age" 1728000 always;
return 204;
}

Solution

1. Step 1: Check origin restriction

   Only add_header "Access-Control-Allow-Origin" "https://example.com" always; if ($request_method = 'OPTIONS') { add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS" always; add_header "Access-Control-Allow-Headers" "Content-Type" always; add_header "Access-Control-Max-Age" 1728000 always; return 204; } restricts origin to "https://example.com" correctly with proper quoting and 'always' parameter.

2. Step 2: Verify OPTIONS preflight handling

   The configuration handles OPTIONS requests by returning 204 with required CORS headers and 'always' to ensure headers are sent.

3. Step 3: Eliminate incorrect options

   Snippets using '*' allow all origins instead of restricting to https://example.com; those lacking full OPTIONS handling, 'always' parameter, or returning 200 instead of 204 fail preflight checks.

4. Final Answer:

   Correctly restricts origin and handles OPTIONS with headers and 204 -> Option D

5. Quick Check:

   Restrict origin + OPTIONS 204 + always = C [OK]

Hint: Use 'always' and return 204 for OPTIONS with restricted origin [OK]

Common Mistakes:

• Using wildcard '*' instead of specific origin
• Not handling OPTIONS preflight properly
• Missing 'always' causing headers to be skipped