Back to Learn
explainer

CORS Misconfiguration: When Your School's API Trusts Everyone

Cross-Origin Resource Sharing (CORS) controls which websites can call your school's APIs. A misconfigured CORS policy can let any website on the internet read your student data or trigger admin actions.

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:

```php

// 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:

```bash

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

```php

$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

```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: *

```

Check Your Site

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

Related Resources