CORS testing in Postman - Deep Dive

Overview - CORS testing

What is it?

CORS testing is the process of checking how a web server handles Cross-Origin Resource Sharing (CORS) requests. CORS is a security feature in browsers that controls how resources on one website can be requested from another domain. Testing CORS ensures that the server allows or blocks requests correctly based on origin rules. This helps prevent unauthorized access to resources from different websites.

Why it matters

Without proper CORS testing, web applications might expose sensitive data to malicious websites or block legitimate requests, causing broken features. This can lead to security breaches or poor user experience. CORS testing helps developers confirm that their server settings protect users while allowing necessary cross-site communication.

Where it fits

Before learning CORS testing, you should understand HTTP basics, web security concepts, and how browsers handle requests. After mastering CORS testing, you can explore advanced web security testing, API testing, and automation of security tests using tools like Postman or Selenium.

Mental Model

Core Idea

CORS testing checks if a server correctly allows or denies web requests coming from different websites to protect user data and functionality.

Think of it like...

Imagine a club with a guest list. The bouncer (browser) checks if a visitor (website) is allowed to enter based on the list (CORS policy). CORS testing is like verifying if the bouncer correctly follows the guest list rules.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Browser sends │──────▶│ Server checks │──────▶│ Server allows │
│ cross-origin  │       │ Origin header │       │ or blocks     │
│ request       │       │ against rules │       │ request       │
└───────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding CORS Basics

Concept: Learn what CORS is and why browsers enforce it.

CORS stands for Cross-Origin Resource Sharing. Browsers restrict web pages from making requests to a different domain than the one that served the page. This is a security measure to prevent malicious sites from stealing data. CORS allows servers to specify which domains can access their resources by sending special headers.

Result

You understand that CORS controls cross-site requests and why it exists.

Knowing the basic purpose of CORS helps you see why testing it is crucial for web security.

2

Foundation

Role of HTTP Headers in CORS

Concept: Identify key HTTP headers involved in CORS communication.

The main headers are Origin (sent by the browser to tell the server where the request comes from), Access-Control-Allow-Origin (sent by the server to allow specific origins), and others like Access-Control-Allow-Methods and Access-Control-Allow-Headers. These headers decide if the browser should allow the request.

Result

You can recognize and explain the purpose of CORS headers in requests and responses.

Understanding headers is essential because CORS testing involves checking these headers for correct values.

3

Intermediate

Using Postman to Simulate CORS Requests

🤔Before reading on: Do you think Postman enforces CORS like browsers do? Commit to your answer.

Concept: Learn how to use Postman to send requests with custom Origin headers to test server CORS behavior.

Postman can send HTTP requests with any headers you set, including Origin. However, Postman itself does not enforce CORS restrictions because it is not a browser. This means you can test how the server responds to different Origin headers by manually adding them in Postman and checking the server's Access-Control-Allow-Origin response.

Result

You can simulate cross-origin requests and observe server responses without browser restrictions.

Knowing that Postman bypasses browser CORS enforcement lets you test server policies directly and catch misconfigurations.

4

Intermediate

Testing Preflight OPTIONS Requests

🤔Before reading on: Does the server always receive a simple GET request for CORS? Commit to your answer.

Concept: Understand and test the preflight OPTIONS request that browsers send before certain CORS requests.

For some requests (like those with custom headers or methods other than GET/POST), browsers send an OPTIONS request first to check if the server allows the actual request. This is called a preflight request. In Postman, you can send an OPTIONS request with Origin and Access-Control-Request-Method headers to test if the server responds with correct CORS headers.

Result

You can verify if the server properly handles preflight requests, which is critical for complex CORS scenarios.

Testing preflight requests prevents bugs where browsers block requests due to missing or incorrect server responses.

5

Intermediate

Validating CORS Headers in Responses

🤔Before reading on: Is it enough for the server to receive the Origin header to allow cross-origin requests? Commit to your answer.

Concept: Learn to check if the server sends correct CORS headers in response to requests.

After sending a request with an Origin header, the server must respond with Access-Control-Allow-Origin matching the Origin or a wildcard '*'. You can inspect response headers in Postman to confirm this. Also, check other headers like Access-Control-Allow-Methods and Access-Control-Allow-Credentials if needed.

Result

You can confirm if the server's CORS policy matches expected security rules.

Validating response headers ensures the server neither blocks legitimate requests nor exposes resources to unauthorized origins.

6

Advanced

Automating CORS Tests in Postman Collections

🤔Before reading on: Can you automate CORS tests to run regularly? Commit to your answer.

Concept: Use Postman's scripting and collection runner to automate repeated CORS tests.

Postman allows writing test scripts in JavaScript to check response headers automatically. You can create collections of requests with different Origin headers and run them in sequence. The tests can assert that Access-Control-Allow-Origin matches expected values and report failures. This automation helps catch regressions quickly.

Result

You have a repeatable, automated way to verify CORS policies during development and deployment.

Automating CORS tests saves time and reduces human error, making security checks consistent and reliable.

7

Expert

Detecting Subtle CORS Misconfigurations

🤔Before reading on: Do you think allowing '*' with credentials is safe? Commit to your answer.

Concept: Identify complex CORS mistakes that can cause security risks or broken functionality.

Some servers mistakenly set Access-Control-Allow-Origin to '*' while also allowing credentials (cookies, authorization headers). Browsers block this combination. Also, servers might reflect the Origin header without validation, allowing any site access. Using Postman, you can test these cases by sending requests with credentials and checking responses. Detecting these subtle errors requires careful header inspection and understanding browser rules.

Result

You can find and fix advanced CORS issues that cause silent failures or security holes.

Recognizing these tricky misconfigurations prevents serious vulnerabilities and improves user experience.

Under the Hood

When a browser makes a cross-origin request, it adds an Origin header showing the source domain. The server checks this header against its allowed list and responds with Access-Control-Allow-Origin if permitted. For complex requests, the browser sends a preflight OPTIONS request first to verify permissions. The browser enforces these rules by blocking responses that don't meet CORS policies, protecting user data from unauthorized sites.

Why designed this way?

CORS was designed to balance security and flexibility. Browsers needed a way to prevent malicious cross-site requests while allowing legitimate resource sharing. The header-based approach lets servers explicitly declare trusted origins. Alternatives like blocking all cross-origin requests were too restrictive, and trusting all origins was insecure. This design allows fine-grained control and backward compatibility.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ Browser     │──────▶│ Server        │──────▶│ Browser       │
│ sends      │ Origin │ checks Origin │ Access-Control-Allow-Origin
│ request    │ header │ against rules │ header sent if allowed
└─────────────┘       └───────────────┘       └───────────────┘
       │
       │
       ▼
┌─────────────┐
│ Browser     │
│ enforces   │
│ CORS rules │
│ blocks or  │
│ allows    │
└─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does setting Access-Control-Allow-Origin to '*' allow all cross-origin requests with credentials? Commit yes or no.

Common Belief: Setting Access-Control-Allow-Origin to '*' allows any website to access resources, even with credentials like cookies.

Reality: Browsers block requests with credentials if Access-Control-Allow-Origin is '*'. The server must specify an exact origin to allow credentials.

Why it matters: Misunderstanding this causes broken login sessions or security holes if developers think '*' is safe with credentials.

Quick: Do you think Postman enforces CORS restrictions like browsers? Commit yes or no.

Common Belief: Postman enforces CORS policies the same way browsers do, so testing CORS in Postman is identical to browser behavior.

Reality: Postman does not enforce CORS because it is not a browser. It sends requests directly and shows server responses without blocking.

Why it matters: Assuming Postman enforces CORS leads to confusion when tests pass in Postman but fail in browsers.

Quick: Does the server always receive a simple GET request for CORS? Commit yes or no.

Common Belief: All cross-origin requests are simple GET requests, so testing only GET is enough for CORS.

Reality: Some requests trigger a preflight OPTIONS request to check permissions before the actual request is sent.

Why it matters: Ignoring preflight requests causes missed bugs where servers reject or mishandle OPTIONS requests, breaking functionality.

Quick: Is reflecting the Origin header in Access-Control-Allow-Origin always safe? Commit yes or no.

Common Belief: Echoing back the Origin header in Access-Control-Allow-Origin is a safe way to allow all origins.

Reality: Reflecting Origin without validation can allow any website to access resources, creating security risks.

Why it matters: This mistake can expose sensitive data to malicious sites, causing data leaks.

Expert Zone

1

Some servers use dynamic CORS policies that change allowed origins based on user authentication or request context, which requires careful testing.

2

CORS headers must be consistent across all server responses, including error pages and redirects, or browsers may block requests unexpectedly.

3

Testing CORS with credentials requires sending cookies or authorization headers in Postman, which is often overlooked but critical for real-world scenarios.

When NOT to use

CORS testing is not needed for same-origin requests or server-to-server API calls where browser security policies do not apply. Instead, use API contract testing or security scanning tools for backend-only communication.

Production Patterns

In production, teams integrate CORS tests into CI pipelines using Postman collections or similar tools. They test multiple origins, methods, and headers automatically. Monitoring tools check live server headers to detect misconfigurations. Some use feature flags to toggle CORS policies safely during deployments.

Connections

Web Security Headers

CORS is part of a broader set of HTTP security headers like CSP and HSTS.

Understanding CORS helps grasp how servers communicate security policies to browsers, complementing other headers that protect users.

API Testing

CORS testing builds on API testing by adding cross-origin context and browser-specific rules.

Knowing API testing basics makes it easier to extend tests for CORS scenarios, ensuring APIs are secure and functional across domains.

Access Control in Physical Security

CORS policies are like physical access control systems that decide who can enter a building.

Seeing CORS as an access control mechanism clarifies why strict rules and checks are necessary to prevent unauthorized access.

Common Pitfalls

#1 Testing CORS only with Postman without considering browser enforcement.

Wrong approach:

Sending requests with Origin headers in Postman and assuming if they succeed, CORS is correctly configured.

Correct approach:

Test CORS in Postman to check server headers, but also verify behavior in real browsers to confirm enforcement.

Root cause:

Confusing Postman's lack of CORS enforcement with actual browser security behavior.

#2 Allowing Access-Control-Allow-Origin: * with credentials enabled.

Wrong approach:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Correct approach:

Access-Control-Allow-Origin: https://trusted.example.com
Access-Control-Allow-Credentials: true

Root cause:

Misunderstanding browser rules that forbid wildcard origins when credentials are involved.

#3 Ignoring preflight OPTIONS requests in testing.

Wrong approach:

Only sending GET or POST requests with Origin header, skipping OPTIONS requests.

Correct approach:

Send OPTIONS requests with Origin and Access-Control-Request-Method headers to test preflight handling.

Root cause:

Not knowing that browsers send preflight requests for certain cross-origin calls.

Key Takeaways

CORS testing ensures servers correctly allow or block cross-origin requests to protect user data and functionality.

Postman can simulate CORS requests by setting Origin headers but does not enforce browser CORS rules itself.

Testing both simple and preflight OPTIONS requests is essential to cover all CORS scenarios.

Automating CORS tests in Postman helps catch regressions and maintain secure configurations.

Understanding subtle CORS misconfigurations prevents security risks and broken user experiences.