Strengthening Web Security: Risks and Solutions for the Absence of Two Key HTTP Response Headers

In the security protection system of web applications, HTTP response headers act as "security gatekeepers". Though they do not directly participate in the implementation of business logic, they can fend off various common web attacks from the source by regulating the browser's resource loading behavior and information transmission rules. Among them, the absence of two key response headers – Content-Security-Policy (CSP) and Referrer-Policy – is a prevalent security loophole in many current web applications. This article will delve into the risks posed by the lack of these two types of response headers and provide specific, implementable configuration solutions for different server environments and development languages.

I. Content-Security-Policy (CSP) Response Header: The "Firewall" Against Cross-Site Scripting (XSS) Attacks

1.1 Risks of Absence: Opening the Floodgates to Cross-Site Scripting (XSS) Attacks

The core role of the Content-Security-Policy (CSP for short) response header is to allow site administrators to precisely control the sources of resources (including scripts, styles, images, fonts, etc.) that user agents (e.g., browsers) can load for the current page. Its policy core centers on specifying legitimate resource server origins and script execution endpoints.

When a web application lacks the CSP response header, browsers will, by default, permit loading resources from any origin. This "unrestricted" loading strategy enables attackers to exploit Cross-Site Scripting (XSS) vulnerabilities to inject and execute malicious scripts in the page seamlessly. For instance, attackers can inject malicious JavaScript code via input scenarios like comment sections and forms. When other users access the page, the browser will load and execute the script indiscriminately, leading to severe security incidents such as user cookie theft, sensitive information leakage, and page tampering.

1.2 Solutions: CSP Configuration Guide for Multiple Server Environments

The core solution to the missing CSP response header issue is to add this header in the server configuration and define reasonable resource loading policies based on business needs. Below are specific configuration methods and official reference docs for mainstream server environments:

1.2.1 Apache Server Configuration

Apache servers implement response header configuration via the mod_headers module, which is usually enabled by default.

1. Open Apache's main config file (httpd.conf) or site-specific config file (e.g., virtual host config file);

2. Add the following content to the config file (the sample policy only allows loading resources from the local site and trusted CDN resources, and can be adjusted per actual needs):

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trust.cdn.com; style-src 'self' https://trust.cdn.com; img-src 'self' data: https://trust.cdn.com"

3. Save the config and restart the Apache service to make the settings take effect;

4. For detailed config rules, refer to Apache's official docs: http://httpd.apache.org/docs/2.2/mod/mod_headers.html.

1.2.2 IIS Server Configuration

IIS servers allow adding the CSP response header via either the graphical interface or config files. Below are the commonly used methods:

1. Graphical interface config: Open "IIS Manager", select the target site, double-click "HTTP Response Headers", click "Add" on the right, enter "Content-Security-Policy" in the "Name" field, input the custom CSP policy in the "Value" field, and click "OK";

2. Config file config: Edit the web.config file in the site's root directory, and add the following content under the <system.webServer> node:

<httpProtocol> <customHeaders> <add name="Content-Security-Policy" value="default-src 'self'; script-src 'self' https://trust.cdn.com" /> </customHeaders> </httpProtocol>

3. No IIS service restart is required for the config to take effect;

4. For detailed config explanations, refer to IIS's official docs: https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx.

1.2.3 Nginx Server Configuration

Nginx supports response header config via the ngx_http_headers_module module, a core Nginx module that requires no additional installation.

1. Open Nginx's main config file (nginx.conf) or site config file (e.g., /etc/nginx/conf.d/xxx.conf);

2. Add the following config under the server or location node:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trust.cdn.com; img-src 'self' https://trust.cdn.com;"; # For compatibility with older browsers, add the X-Content-Security-Policy header add_header X-Content-Security-Policy "default-src 'self'; script-src 'self' https://trust.cdn.com;";

3. Save the config, execute "nginx -t" to verify no config errors, then run "nginx -s reload" to restart the Nginx service;

4. For detailed module descriptions, refer to Nginx's official docs: http://nginx.org/en/docs/http/ngx_http_headers_module.html.

II. Referrer-Policy Response Header: The "Safety Valve" for Regulating Information Transmission

2.1 Risks of Absence: Leaking Source Information and Invalidating Browser Security Features

The Referrer-Policy response header controls whether the browser carries Referrer information and the scope of the carried information when sending HTTP requests. Referrer information records the URL of the request's source page, which is often used in scenarios like user behavior analysis and source statistics, but it can also become a channel for information leakage.

When a web application lacks the Referrer-Policy response header, browsers adopt the default Referrer policy, which may carry the full source page URL in all requests. This not only results in excessive collection of users' browsing behavior information but also invalidates Referrer-related security features provided by browsers. For example, when jumping from an HTTPS encrypted page to an HTTP unencrypted page, the default policy may still carry the full Referrer, leading to leakage of sensitive information (e.g., parameters in the URL) in the encrypted page via the Referrer, increasing the risk of web front-end attacks.

2.2 Solutions: Dual Configuration Schemes for Server-Side and Proxy Servers

Referrer-Policy can be configured either by directly modifying server-side program code or via load balancing/reverse proxy servers. The core is to select appropriate rules from optional policies, common ones include: no-referrer (no Referrer carried), same-origin (carried only for same-origin requests), strict-origin-when-cross-origin (only origin info carried for cross-origin requests), etc.

2.2.1 Server-Side Program Code Configuration

For server-side of different development languages, the Referrer-Policy header can be added directly to HTTP responses via code:

• Java server-side: Set via the setHeader method in the response object, sample code: // In frameworks like Servlet or Spring MVC response.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
• PHP server-side: Use the header function to add the response header (ensure to call it before outputting content), sample code: header("Referrer-Policy: same-origin");
• ASP server-side: Configure via the Response.AddHeader method, sample code: Response.AddHeader "Referrer-Policy", "no-referrer-when-downgrade"
• Python Django server-side: Set the response header in the HttpResponse object, sample code: from django.http import HttpResponsedef demo_view(request):response = HttpResponse("Hello World")response["Referrer-Policy"] = "origin-when-cross-origin"return response
• Python Flask server-side: Create a response object via make_response and set header info, sample code: from flask import Flask, make_responseapp = Flask(__name__)@app.route('/')def index():response = make_response("Hello Flask")response.headers["Referrer-Policy"] = "strict-origin"return response

2.2.2 Proxy Server Configuration

If the web application uses load balancing or reverse proxy servers (e.g., Nginx, Apache), the Referrer-Policy response header can be configured directly in the proxy server without modifying server-side code – suitable for unified management of multiple services:

• Nginx/Tengine/Openresty: Add the add_header directive under the server or location node of the site config, sample code: add_header Referrer-Policy strict-origin-when-cross-origin; After config, execute "nginx -s reload" to restart the service for it to take effect.
• Apache: Use the Header directive in the main config file or site config file, sample code: Header add Referrer-Policy "same-origin" Save and restart the Apache service to make the config take effect.

III. Summary: Incorporate Response Header Configuration into Web Security Baseline

The absence of Content-Security-Policy and Referrer-Policy response headers may seem like minor config issues, but they can plant major security risks in web applications. These two response headers build security protection from two dimensions – "resource loading control" and "source information regulation" – and are low-cost, high-impact basic measures in the web security protection system.

Developers and O&M personnel should incorporate the configuration of these two response headers into the web application's security baseline, and select appropriate policies based on business scenarios: For CSP, avoid overly loose configs and prioritize the "principle of least privilege"; For Referrer-Policy, select rules that protect information security without affecting business functions based on the page's encryption level (HTTP/HTTPS) and cross-domain requirements. By standardizing response header configuration, enhance the web application's security protection capability from the source and resist various front-end attack risks.