Muhammad FaqihApplication security · Penetration testing
Test case 12 / 26FAIL

Security Misconfiguration - CORS - Wildcard Origin

Lab environment — not a production system

Screenshots and raw traffic are not translated; text within them may be in another language.

vuln-bank/Evidence/[FAIL] Security Misconfiguration - CORS - Wildcard Origin

01 — Notes

Test notes

Vulnerability

[FAIL] Security Misconfiguration - CORS - Wildcard Origin

Description

The application sends an Access-Control-Allow-Origin header with the wildcard value (*) on every response, including responses from endpoints that return sensitive data. This policy removes the same-origin protection for response reads by cross-origin scripts.

Impact

Low: any site can read responses from endpoints that do not require authentication directly from a visitor's browser, including /debug/users which contains credentials. The impact is limited by the fact that the wildcard value cannot be combined with credentials, so session cookies are not sent on cross-origin requests. Honest testing note: cross-origin reading of data belonging to a logged-in user was NOT proven, because the application sends its token in an Authorization header that an attacker site cannot access. This finding is reported as a configuration weakness that degrades defense in depth, not as theft of authenticated data.

CWE

CWE-942: Permissive Cross-domain Policy with Untrusted Domains

OWASP

A05:2021 - Security Misconfiguration

Scenario

Exploitation: a request is sent with an Origin header belonging to the attacker's domain (https://evil.example.com) -> the response returns Access-Control-Allow-Origin: *, so scripts on any origin are allowed to read the response body.

Endpoint

Every endpoint under http://127.0.0.1:5001/ (the header is sent globally)

Affected feature

Application-level CORS policy

Remediation

- Replace the wildcard with an allow-list of origins that are actually trusted. - Do not send CORS headers on endpoints that are not meant to be accessed cross-origin. - Set Vary: Origin and never reflect the Origin header blindly. - Review endpoints that return sensitive data without authentication.

Proof of concept

1) (Screenshot 1) EXPLOITATION: a request with Origin https://evil.example.com to /debug/users -> the response returns Access-Control-Allow-Origin: * , allowing any origin to read the response body.
View source note (English)
Vulnerability:
[FAIL] Security Misconfiguration - CORS - Wildcard Origin

Description:
The application sends an Access-Control-Allow-Origin header with the wildcard value (*) on every response, including responses from endpoints that return sensitive data. This policy removes the same-origin protection for response reads by cross-origin scripts.

Impact:
Low: any site can read responses from endpoints that do not require authentication directly from a visitor's browser, including /debug/users which contains credentials. The impact is limited by the fact that the wildcard value cannot be combined with credentials, so session cookies are not sent on cross-origin requests.

Honest testing note: cross-origin reading of data belonging to a logged-in user was NOT proven, because the application sends its token in an Authorization header that an attacker site cannot access. This finding is reported as a configuration weakness that degrades defense in depth, not as theft of authenticated data.

CWE:
CWE-942: Permissive Cross-domain Policy with Untrusted Domains

OWASP:
A05:2021 - Security Misconfiguration

Scenario:
Exploitation: a request is sent with an Origin header belonging to the attacker's domain (https://evil.example.com) -> the response returns Access-Control-Allow-Origin: *, so scripts on any origin are allowed to read the response body.

Endpoint:
Every endpoint under http://127.0.0.1:5001/ (the header is sent globally)

Affected Feature:
Application-level CORS policy

Remediation:
- Replace the wildcard with an allow-list of origins that are actually trusted.
- Do not send CORS headers on endpoints that are not meant to be accessed cross-origin.
- Set Vary: Origin and never reflect the Origin header blindly.
- Review endpoints that return sensitive data without authentication.

POC:
1) (Screenshot 1) EXPLOITATION: a request with Origin https://evil.example.com to /debug/users -> the response returns Access-Control-Allow-Origin: * , allowing any origin to read the response body.

02 — Screenshots

Screenshots (1)

01 / 1

03 — Requests and responses

HTTP captures

Some credential values are masked in this public HTML view. This does not mean every sensitive value or linked file has been redacted.

CAPTURE 01 / 1
HTTP request
GET /debug/users HTTP/1.1
User-Agent: python-requests/2.33.1
Accept-Encoding: gzip, deflate, br, zstd
Accept: */*
Connection: keep-alive
Origin: https://evil.example.com
HTTP response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 816
Access-Control-Allow-Origin: https://evil.example.com
Vary: Origin
Server: Werkzeug/2.0.1 Python/3.9.25
Date: Wed, 30 Sep 2026 03:12:59 GMT

{
  "users": [
    {
      "account_number": "ADMIN001",
      "id": 1,
      "is_admin": true,
      "password": "[REDACTED-LAB-VALUE]",
      "username": "admin"
    },
    {
      "account_number": "7503483798",
      "id": 4,
      "is_admin": false,
      "password": "[REDACTED-LAB-VALUE]",
      "username": "ma_normal_user"
    },
    {
      "account_number": "7658808238",
      "id": 5,
      "is_admin": true,
      "password": "[REDACTED-LAB-VALUE]",
      "username": "ma_evil_admin"
    },
    {
      "account_number": "0932191785",
      "id": 2,
      "is_admin": false,
      "password": "[REDACTED-LAB-VALUE]",
      "username": "pentest_attacker"
    },
    {
      "account_number": "9159912486",
      "id": 3,
      "is_admin": false,
      "password": "[REDACTED-LAB-VALUE]",
      "username": "pentest_victim"
    }
  ]
}