Problem Statement
The application currently lacks a robust configuration for HTTP security headers. Without a strict Content Security Policy (CSP) and sanitized headers, the platform is vulnerable to Cross-Site Scripting (XSS), clickjacking, and information leakage (such as stack details via the X-Powered-By header). Additionally, there is a risk of Admin API endpoints or sensitive environment variables being inadvertently exposed to the client-side bundle without proper build-time validation.
Current Behavior / Limitation
- Missing Headers: Responses from the server do not include
Content-Security-Policy, Strict-Transport-Security, or X-Content-Type-Options.
- Information Leakage: The
X-Powered-By header is likely enabled by default (revealing "Express"), which assists attackers in fingerprinting the technology stack.
- Env Var validation: Client-side environment variables are currently consumed without a centralized validation step, increasing the risk of undefined behavior or accidental exposure of server-side secrets to the frontend.
Expected Improvement
The application should implement a "defense-in-depth" strategy regarding HTTP responses:
- Strict CSP: A whitelist approach to script sources, style sources, and connection endpoints.
- Obfuscation: Removal of framework-identifying headers.
- Sanitization: A build-time script that validates necessary client-side environment variables and ensures no server-side secrets are leaked to the browser.
Proposed Approach
1. Middleware Implementation (server/index.js)
- Install and configure
helmet for Express.
- Explicitly configure the CSP module within Helmet to:
- Restrict
script-src to 'self' and trusted CDNs (if any).
- Restrict
connect-src to the application's API endpoints.
- Disable the
X-Powered-By header.
2. Vercel Configuration (vercel.json)
- Update the
headers key in vercel.json to enforce security headers at the edge/deployment level. This acts as a fallback and ensures static assets served directly by Vercel also receive these headers.
3. Environment Sanitization (src/config/envConfig.js)
- Implement a validation schema (using a library like
Joi, Zod, or a custom utility).
- Ensure the script runs during the build process. It should throw an error if:
- Required
REACT_APP_ (or NEXT_PUBLIC_) variables are missing.
- Variables intended for the server (e.g.,
ADMIN_SECRET) are detected in the client config file.
Verification Steps
To verify the implementation, please follow these steps:
-
Header Inspection:
- Start the server locally:
npm run dev.
- Open your browser's Developer Tools -> Network Tab.
- Refresh the page and click the primary document request (usually
localhost).
- Verify: Look for
Content-Security-Policy. It should exist and contain restrictive rules (not *).
- Verify: Ensure
X-Powered-By is NOT present in the response headers.
-
CLI Verification (cURL):
- Run:
curl -I http://localhost:3000 (or your specific port).
- Check the output to confirm
X-DNS-Prefetch-Control, X-Frame-Options, and Strict-Transport-Security are present.
-
Test Environment Validation:
- Temporarily remove a required client-side environment variable from your
.env file.
- Run the build command:
npm run build.
- Verify: The build should fail with a clear error message indicating the missing variable.
-
CSP Violation Test:
- Temporarily add an external script tag (e.g.,
<script src="https://example.com/malicious.js"></script>) to public/index.html.
- Run the app and open the Browser Console.
- Verify: You should see a generic CSP violation error refusing to load the script.
Labels: ECWoC26
Problem Statement
The application currently lacks a robust configuration for HTTP security headers. Without a strict Content Security Policy (CSP) and sanitized headers, the platform is vulnerable to Cross-Site Scripting (XSS), clickjacking, and information leakage (such as stack details via the
X-Powered-Byheader). Additionally, there is a risk of Admin API endpoints or sensitive environment variables being inadvertently exposed to the client-side bundle without proper build-time validation.Current Behavior / Limitation
Content-Security-Policy,Strict-Transport-Security, orX-Content-Type-Options.X-Powered-Byheader is likely enabled by default (revealing "Express"), which assists attackers in fingerprinting the technology stack.Expected Improvement
The application should implement a "defense-in-depth" strategy regarding HTTP responses:
Proposed Approach
1. Middleware Implementation (
server/index.js)helmetfor Express.script-srcto'self'and trusted CDNs (if any).connect-srcto the application's API endpoints.X-Powered-Byheader.2. Vercel Configuration (
vercel.json)headerskey invercel.jsonto enforce security headers at the edge/deployment level. This acts as a fallback and ensures static assets served directly by Vercel also receive these headers.3. Environment Sanitization (
src/config/envConfig.js)Joi,Zod, or a custom utility).REACT_APP_(orNEXT_PUBLIC_) variables are missing.ADMIN_SECRET) are detected in the client config file.Verification Steps
To verify the implementation, please follow these steps:
Header Inspection:
npm run dev.localhost).Content-Security-Policy. It should exist and contain restrictive rules (not*).X-Powered-Byis NOT present in the response headers.CLI Verification (cURL):
curl -I http://localhost:3000(or your specific port).X-DNS-Prefetch-Control,X-Frame-Options, andStrict-Transport-Securityare present.Test Environment Validation:
.envfile.npm run build.CSP Violation Test:
<script src="https://example.com/malicious.js"></script>) topublic/index.html.Labels: ECWoC26