You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement analyzers for legacy browser-specific security headers:
- X-XSS-Protection: Validates XSS filter configuration (recommends disabling)
- X-Download-Options: Validates IE download execution prevention
- X-Permitted-Cross-Domain-Policies: Validates Flash/PDF cross-domain policies
All analyzers follow OWASP and Mozilla best practices:
- X-XSS-Protection: Best practice is '0' (explicitly disabled)
- X-Download-Options: Requires 'noopen' value
- X-Permitted-Cross-Domain-Policies: Best is 'none', acceptable is 'master-only'
Changes:
- Add sha/analyzers/x_xss_protection.py with full validation logic
- Add sha/analyzers/x_download_options.py with noopen validation
- Add sha/analyzers/x_permitted_cross_domain_policies.py with policy validation
- Register all 3 analyzers in sha/analyzers/__init__.py
- Update docs/SecurityHeadersBestPractices.md with detailed header documentation
Copy file name to clipboardExpand all lines: docs/SecurityHeadersBestPractices.md
+90-1Lines changed: 90 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -163,6 +163,92 @@ Without Referrer-Policy, clicking any external link would send this full URL (in
163
163
164
164
---
165
165
166
+
## 6. X-XSS-Protection
167
+
168
+
**Purpose:** Legacy header that controlled browser XSS filters in Internet Explorer, Chrome, and Safari. Now deprecated in modern browsers.
169
+
170
+
**Best Practice:**
171
+
```
172
+
X-XSS-Protection: 0
173
+
```
174
+
Explicitly disables the XSS filter. This is the modern recommendation because these filters can introduce XSS vulnerabilities in otherwise safe websites.
175
+
176
+
**Acceptable:**
177
+
Not setting the header at all is acceptable for modern applications that implement a strong Content-Security-Policy.
178
+
179
+
**Bad/Missing:**
180
+
-`X-XSS-Protection: 1` (enables the filter without mode=block, can create vulnerabilities)
181
+
-`X-XSS-Protection: 1; mode=block` (legacy approach, filter can introduce bugs)
182
+
183
+
**Severity if Missing:** Low
184
+
185
+
**Reasoning:** Modern browsers have removed XSS filter functionality, and Content-Security-Policy provides superior protection. However, explicitly setting `0` prevents older browsers from using potentially buggy XSS filters. OWASP recommends either not setting this header or explicitly disabling it with `0` to avoid filter-based vulnerabilities.
**Purpose:** Internet Explorer 8+ specific header that prevents the browser from executing downloaded HTML files in the context of the site. Prevents Same Origin Policy violations during file downloads.
196
+
197
+
**Best Practice:**
198
+
```
199
+
X-Download-Options: noopen
200
+
```
201
+
Forces users to save the file before opening it, preventing execution in the site's security context.
202
+
203
+
**Acceptable:**
204
+
Same as best practice. This header has only one valid value: `noopen`.
205
+
206
+
**Bad/Missing:**
207
+
- Header not present when serving user-controllable HTML content with `Content-Disposition: attachment`
208
+
- Any value other than `noopen`
209
+
210
+
**Severity if Missing:** Low
211
+
212
+
**Reasoning:** When a user directly opens a downloaded HTML file in IE, scripts in that file can access cookies from the originating domain. This violates the Same Origin Policy by allowing the downloaded file to execute as if it were part of the website. Setting this header forces the save-then-open workflow, ensuring downloaded files execute in a local context. While IE-specific and legacy, this header is still recommended when serving downloadable HTML content.
**Purpose:** Controls whether Adobe Flash Player, Adobe Acrobat, or PDF documents can load cross-domain policy files from the web server. Prevents untrusted Flash/PDF content from accessing site data.
223
+
224
+
**Best Practice:**
225
+
```
226
+
X-Permitted-Cross-Domain-Policies: none
227
+
```
228
+
Completely prohibits Flash and PDF clients from loading any cross-domain policy files. Most secure option.
229
+
230
+
**Acceptable:**
231
+
```
232
+
X-Permitted-Cross-Domain-Policies: master-only
233
+
```
234
+
Allows only the master policy file (`/crossdomain.xml`) to be loaded. Acceptable if you need to support legacy Flash/PDF content with controlled cross-domain access.
235
+
236
+
**Bad/Missing:**
237
+
- Header not present (allows policy files from any location)
238
+
-`all`: Allows policy files from anywhere on the server (very insecure)
239
+
-`by-content-type`: Allows policy files served with `Content-Type: text/x-cross-domain-policy` (too permissive)
240
+
-`by-ftp-filename`: Allows policy files with specific FTP filenames (legacy, insecure)
241
+
242
+
**Severity if Missing:** Medium
243
+
244
+
**Reasoning:** While Adobe Flash is deprecated (EOL December 2020), this header remains relevant for security audits and defense-in-depth. Without proper configuration, attackers could place a malicious `crossdomain.xml` file on your server, allowing Flash/PDF content from other domains to read your application's data and bypass CSRF protections. Many security scanners still check for this header. Setting it to `none` is a simple, zero-cost protection.
0 commit comments