Configuring security response headers can effectively prevent client-side intrusions.
Detection Websites#
Introduction and Configuration#
HTTP Strict Transport Security (HSTS)#
HTTP transmits data in plaintext, with no encryption, meaning anyone can intercept all content transmitted between the browser and the server. Therefore, the TLS encryption used by HTTPS is highly commendable. However, unless specifically designated as HTTPS, each time a domain is accessed, an HTTP request is first sent to the server, which then redirects to the browser, and only then does the browser upgrade to HTTPS.
HSTS is the solution to this problem.
When the browser receives the Strict-Transport-Security header sent by an HTTPS site, it will comply with the specified time to enforce HTTPS access. If the browser revisits the site before the specified time has elapsed, it will not send an HTTP request but will directly use the HTTPS connection, preventing attacks such as SSL stripping against connections that have not yet upgraded to HTTPS.
e.g.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
This header has three parameters: max-age=63072000, includeSubDomains, and preload.
max-age=indicates the duration to maintain the HTTPS connection, followed by the number of seconds, e.g.,max-age=31536000means to use HTTPS connections for one year.includeSubDomainsindicates that all subdomains under this domain should also use HTTPS access.
HSTS is great, but the very first connection is always HTTP. What if a long-planned script kiddie penetration expert is always watching every move?
The preload parameter addresses this issue. Browsers obtain sites that should directly use HTTPS connections from the Chrome or Firefox preload lists. This list can be actively submitted at HSTSpreload.
The list can be queried and modified locally on Chrome at chrome://net-internals/#hsts.
X-Frame-Options#
It is recommended to use CSP parameters instead.
TheContent-Security-Policyresponse header has aframe-ancestorsparameter that can perfectly replace theX-Frame-Optionsresponse header and has more features.
The X-Frame-Options HTTP response header is used to indicate to the browser whether a page can be displayed in a
<frame>,<iframe>,<embed>, or<object>. Sites can avoid clickjacking attacks by ensuring that their site is not embedded in others.
e.g.
X-Frame-Options: SAMEORIGIN
This header has only two parameters, SAMEORIGIN and DENY.
SAMEORIGINindicates that the page only allows frames from the same origin domain.DENYindicates that no frames are allowed at all.
X-Content-Type-Options#
The main purpose of this header is to require the client to strictly adhere to the file MIME type specified in the Content-Type response header. Otherwise, the browser may use MIME-sniffing to guess the content of the returned file and execute it.
If this header is not configured, javascript and css hidden in images or other media files could be exploited by attackers to penetrate the system.
e.g.
X-Content-Type-Options: nosniff
This header has only one parameter, nosniff, to inform the client.
nosniffwill prevent requests from occurring that do not match the MIME type.
X-XSS-Protection#
Browser Compatibility
Currently, only Safari still supports this header.
This header can be replaced by a fully configured CSP header.
The purpose of this header is as clear as its name, to protect against XSS attacks based on the browser, and it is not part of any specification or draft.
e.g.
X-XSS-Protection: 1; mode=block
This header has four parametersquoted from Mdn:
-
0disables XSS filtering. -
1enables XSS filtering. If a cross-site scripting attack is detected, the browser will clear the page (removing unsafe parts). -
1;mode=blockenables XSS filtering. If an attack is detected, the browser will not clear the page but will block the page from loading. -
1; report=<reporting-URI>is supported only in Chrome versions 4-77. This parameter indicates that XSS filtering is enabled. If a cross-site scripting attack is detected, the browser will clear the page and send a violation report using the CSP report-uri feature.
Permissions Policy#
This header can be used to control the browser features accessible to the page, allowing the site to define the possible permission scope in advance.
e.g.
Permissions-Policy: geolocation=()
This header has many parameters, with the syntax being <directive>=<allowlist>, where the first part indicates the permission and the second part indicates the allowed whitelist.
Permission List
Whether to allow setting document.domain.
Whether to allow using the Encrypted Media Extensions API (EME).
Whether tasks should execute in frames when not rendered.
Whether tasks should execute in frames when outside the visible viewport.
Whether to allow using Element.requestFullscreen().
Whether to allow using the Gamepad API.
Whether to allow using the Geolocation API.
Whether to allow collecting information about device orientation through the interface.
Whether to allow using the WebHID API to connect to uncommon or unusual human interface devices, such as alternative keyboards or game controllers.
Whether to allow using the Idle Detection API to detect when users interact with their devices.
Whether to allow collecting data about user-installed local fonts.
Whether to allow collecting information about device orientation through the interface.
Whether to allow using audio input devices.
Whether to allow using the Web MIDI API.
Whether to allow using the Payment Request API.
Whether to allow playing videos in picture-in-picture mode through the corresponding API.
Whether to allow using the Web Authentication API to retrieve stored public key credentials.
Whether to allow using the Screen Wake Lock API to indicate that the device should not turn off or dim the screen.
Whether to allow using the Web Serial API to communicate with serial devices, directly connecting through serial ports, or simulating serial ports via USB or Bluetooth devices.
Whether to allow using the Audio Output Device API to list and select speakers.
Whether to allow using the Web USB API.
Whether to allow using Navigator.share(), the Web Share API to share text, links, images, and other content to any destination chosen by the user, such as mobile applications.
Whether to allow using the WebXR Device API to interact with WebXR sessions.
Whether to allow collecting information about device acceleration.
Whether to allow collecting information about brightness in the surrounding environment of the device.
Whether to allow autoplay of media requested through HTMLMediaElement.
Whether to allow using the Battery Status API.
Whether to allow using video input devices.
Whether to allow using the getDisplayMedia() method to capture screen content.
The whitelist can have three values:
*: Allows the current page and all content presented on the page to use this feature.(): Does not allow the use of this feature.(self "https://example.org"): This parameter allows the use of wildcards, with each allowed site separated by spaces, whereselfrefers to the current page.
Content Security Policy (CSP)#
This header defines what content is allowed to be used and executed by the page.
CSP configuration is complex; for details, you can check out the blog by Ruanyifeng Introduction to Content Security Policy.
I don't want to reinvent the wheel not because I'm too lazy to write.
After configuring the CSP header, you can also use Google's CSP Evaluator to check if your CSP policy is strong.
Scoring#
The two detection websites at the top can check response headers. The detection by Securityheaders is not as strict as that of Mozilla; generally speaking, if the detection achieves an A+, it indicates that the security response headers are configured properly.
