CORS Misconfiguration: When Your School's API Trusts Everyone

What Is CORS?

Browsers enforce a security rule called the Same-Origin Policy: JavaScript on one website cannot read responses from a different website's server. This prevents malicious-site.com from using a visitor's browser to silently read data from yourschool.edu.ph.

Cross-Origin Resource Sharing (CORS) is a mechanism that lets servers selectively relax this rule — telling browsers "it's okay for JavaScript from these specific trusted origins to read my responses."

It works through HTTP headers:

Access-Control-Allow-Origin: https://partner.edu.ph
Access-Control-Allow-Credentials: true

What Goes Wrong: Common Misconfigurations

1. Wildcard with credentials

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

This combination is actually blocked by browsers — but many developers work around it by dynamically reflecting the requester's origin:

// Dangerous pattern seen in many school CMS backends:
header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']);
header("Access-Control-Allow-Credentials: true");

This effectively trusts every origin on the internet. Any website can make requests to your API and read the responses — including authenticated responses carrying student data.

2. Overly broad wildcard

Access-Control-Allow-Origin: *

For public, unauthenticated APIs, this is fine. But if your API returns anything sensitive — even aggregate stats — a wildcard exposes it to any JavaScript anywhere.

3. Trusting null origin

Access-Control-Allow-Origin: null

The null origin is sent by sandboxed iframes and local files. Trusting it is effectively the same as a wildcard in many attack scenarios.

Real Impact for Schools

An attacker creates a webpage that students or staff are tricked into visiting (e.g., via phishing). That page's JavaScript silently:

1. 1Calls your school's API using the victim's browser (and their authenticated session cookie)
2. 2Reads the response — which your misconfigured CORS policy permits
3. 3Exfiltrates the data to the attacker's server

The victim sees nothing. The data — student records, grades, contact information — is gone.

How to Check for CORS Misconfiguration

Send a request to your API with a custom Origin header:

curl -H "Origin: https://evil.com" -I https://yourschool.edu.ph/api/students

If the response includes:

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

Your API is misconfigured.

How to Fix CORS

Use an explicit whitelist

$allowed = ['https://yourschool.edu.ph', 'https://portal.yourschool.edu.ph'];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if (in_array($origin, $allowed)) {
    header("Access-Control-Allow-Origin: $origin");
    header("Access-Control-Allow-Credentials: true");
}

Nginx

set $cors_origin "";
if ($http_origin ~* "^https://(yourschool\.edu\.ph|portal\.yourschool\.edu\.ph)$") {
    set $cors_origin $http_origin;
}
add_header Access-Control-Allow-Origin $cors_origin always;

For public APIs with no credentials

A wildcard is acceptable only when:

• The endpoint returns no user-specific data
• No session cookies or auth tokens are used
• The data is genuinely public

Access-Control-Allow-Origin: *

Try the Live Demo

Interactive CORS Demo: Enter a school API domain and watch an attacker page silently fetch and read student records when CORS is set to *. Switch to the protected mode to see the browser block the read with a CORS error.

Launch CORS Misconfiguration Demo →

Check Your Site

The Site Scanner inspects your school site's CORS headers and flags overly permissive configurations.

Related Resources

• Cookie Security Flags — securing the credentials CORS attacks exploit
• Sensitive Paths Exposed — other common API exposure issues
• Common Attack Vectors in Philippine Schools — how API misconfigurations lead to breaches