📖 Scenario: You are setting up a web server using nginx. Your website needs to allow other websites to request resources from it safely. This is done by configuring CORS (Cross-Origin Resource Sharing) headers.
🎯 Goal: You will create an nginx configuration that allows cross-origin requests from a specific website by adding the correct CORS headers.
📋 What You'll Learn
Create a basic nginx server block configuration
Add a variable to hold the allowed origin URL
Add the CORS headers using the variable
Print the final nginx configuration to verify
💡 Why This Matters
🌍 Real World
Web servers often need to allow safe cross-origin requests for APIs or resources. Configuring CORS headers in nginx is a common task to enable this.
💼 Career
DevOps and site reliability engineers frequently configure nginx for web applications. Understanding CORS setup helps ensure secure and functional web services.
Progress0 / 4 steps
1
Create basic nginx server block
Create a basic nginx server block configuration with server listening on port 80 and serving from /var/www/html.
Nginx
Hint
Use server { ... } block with listen 80; and root /var/www/html;.
2
Add allowed origin variable
Add a variable called $allowed_origin and set it to https://example.com inside the server block.
Nginx
Hint
Use set $allowed_origin "https://example.com"; inside the server block.
3
Add CORS headers
Inside the server block, add a location / block. Inside it, add these headers using add_header: Access-Control-Allow-Origin set to $allowed_origin, Access-Control-Allow-Methods set to GET, POST, OPTIONS, and Access-Control-Allow-Headers set to Origin, Content-Type, Accept.
Nginx
Hint
Use location / { ... } and add the three add_header lines inside it.
4
Print final nginx configuration
Print the entire nginx configuration to verify it includes the server block with the set $allowed_origin and the location / block with the CORS headers.
Nginx
Hint
Print the full nginx configuration text exactly as written.
Practice
(1/5)
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
Step 1: Understand CORS purpose
CORS (Cross-Origin Resource Sharing) controls which external websites can request resources from your server.
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.
Final Answer:
To control which websites can access server resources -> Option A
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
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 "*".
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.
Final Answer:
add_header Access-Control-Allow-Origin "*"; -> Option C
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:
What will be the HTTP status code returned for an OPTIONS request?
medium
A. 200
B. 204
C. 400
D. 500
Solution
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.
Step 2: Identify the return status code
The line return 204; explicitly sends HTTP status 204 (No Content) for OPTIONS requests.
Final Answer:
204 -> Option B
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
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.
Step 2: Identify missing 'always' parameter
Without 'always', CORS headers may not be sent on OPTIONS or error responses, causing browser blocks.
Final Answer:
The add_header directive is inside a location block without 'always' parameter -> Option A
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
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.
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.
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.
Final Answer:
Correctly restricts origin and handles OPTIONS with headers and 204 -> Option D
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.