Cors Wildcard in Express with Basic Auth
Cors Wildcard in Express with Basic Auth — how this specific combination creates or exposes the vulnerability
In Express, a CORS wildcard (Access-Control-Allow-Origin: *) combined with Basic Authentication creates a critical cross-origin information leak. When credentials are required (e.g., Authorization headers), browsers enforce strict origin checks and will not allow wildcard origins to satisfy CORS preflight or actual requests. If a server incorrectly allows both a wildcard origin and presents Basic Auth challenges, it may expose authenticated responses to origins that should be denied.
Consider a typical misconfiguration where app.use(cors({ origin: '*', credentials: true })) is used alongside Basic Auth middleware. The credentials: true flag signals to the browser that cookies or authentication headers are included in cross-origin requests. However, the server’s Access-Control-Allow-Origin header remains a literal asterisk. Modern browsers reject such responses, but misconfigured preflight responses or non-browser clients may accept them. Attackers can craft cross-origin requests from a malicious page, leveraging the exposed Authorization header to infer valid credentials or session behavior through timing or error differences.
During a middleBrick scan, this setup is flagged under Authentication and BOLA/IDOR checks. The scanner detects permissive CORS headers alongside authentication mechanisms and tests whether authenticated responses are delivered to an unrestricted origin. For example, a preflight request with Origin: https://evil.com and Access-Control-Request-Headers: authorization may receive an Access-Control-Allow-Origin: * response. Even if the browser blocks the actual response, the presence of a wildcard with authorization headers indicates a configuration flaw that can be abused in non-browser contexts or legacy clients.
Real-world impact includes unauthorized cross-origin access to authenticated endpoints, potentially exposing Basic Auth credentials transmitted in the Authorization header. This maps to OWASP API Top 10 A05:2023 Security Misconfiguration and can intersect with BOLA/IDOR when unauthorized origins can enumerate or interact with authenticated resources. middleBrick’s OpenAPI/Swagger analysis cross-references the spec’s securitySchemes and CORS-related headers with runtime findings, highlighting discrepancies between declared and actual CORS policies.
Basic Auth-Specific Remediation in Express — concrete code fixes
Remediation focuses on aligning CORS policy with authentication requirements. Basic Auth requires explicit origin restrictions and proper handling of preflight requests. Never pair a wildcard origin with credentials. Instead, specify trusted origins and ensure preflight responses include the correct headers.
Example of a secure Express configuration using the cors package with Basic Auth:
const express = require('express');
const cors = require('cors');
const app = express();
const allowedOrigins = ['https://trusted.example.com', 'https://app.example.com'];
const corsOptions = {
origin: function (origin, callback) {
if (!origin || allowedOrigins.indexOf(origin) !== -1) {
callback(null, true);
} else {
callback(new Error('Not allowed by CORS'));
}
},
credentials: true,
allowedHeaders: ['Authorization', 'Content-Type'],
exposedHeaders: ['Content-Length'],
optionsSuccessStatus: 200
};
app.use(cors(corsOptions));
This configuration ensures that only known origins can make authenticated requests. The dynamic origin check prevents open redirects and reflects the client’s origin safely. The server responds with Access-Control-Allow-Origin set to the specific origin, not a wildcard, when credentials are included.
For Basic Auth, ensure the Authorization header is allowed in CORS requests:
const basicAuth = require('express-basic-auth');
app.use(basicAuth({
users: { 'admin': 'S3cur3P@ss!' },
challenge: true,
realm: 'Secure Area'
}));
Combine this with CORS as shown above. The server should respond with 401 Unauthorized and a proper WWW-Authenticate header when credentials are missing or invalid. Validate that preflight responses include Access-Control-Allow-Methods and Access-Control-Allow-Headers for the actual request’s method and headers.
middleBrick’s per-category breakdowns highlight CORS and Authentication findings, providing prioritized remediation steps. The scanner verifies that endpoints requiring authentication do not respond with wildcard origins and that preflight responses are strict. Using the CLI (middlebrick scan <url>) or GitHub Action, teams can enforce these rules in CI/CD, failing builds when risky configurations are detected.
Related CWEs: dataExposure
| CWE ID | Name | Severity |
|---|---|---|
| CWE-200 | Exposure of Sensitive Information | HIGH |
| CWE-209 | Error Information Disclosure | MEDIUM |
| CWE-213 | Exposure of Sensitive Information Due to Incompatible Policies | HIGH |
| CWE-215 | Insertion of Sensitive Information Into Debugging Code | MEDIUM |
| CWE-312 | Cleartext Storage of Sensitive Information | HIGH |
| CWE-359 | Exposure of Private Personal Information (PII) | HIGH |
| CWE-522 | Insufficiently Protected Credentials | CRITICAL |
| CWE-532 | Insertion of Sensitive Information into Log File | MEDIUM |
| CWE-538 | Insertion of Sensitive Information into Externally-Accessible File | HIGH |
| CWE-540 | Inclusion of Sensitive Information in Source Code | HIGH |
Frequently Asked Questions
Why does a CORS wildcard with Basic Auth cause a security risk even if browsers block the response?
How can I verify my Express CORS and Basic Auth setup is secure?
middlebrick scan <your-api-url> to get a detailed report on CORS headers, authentication mechanisms, and preflight behavior. Check that Access-Control-Allow-Origin is not a wildcard when credentials are required and that only specific origins are allowed.