# upgrade-insecure-requests directive present

- **Pattern:** `ab-002447` (`security-headers-ii.permissions-depth.upgrade-insecure-requests`)
- **Severity:** medium
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002447
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002447)

## Why it matters

Mixed content — HTTP resources on HTTPS pages — is blocked or flagged by modern browsers, but the underlying cause is often hardcoded `http://` URLs in templates, user-generated content, or legacy code. `upgrade-insecure-requests` acts as a browser-side safety net that auto-upgrades HTTP subresource requests to HTTPS, preventing mixed-content blocks from silently breaking functionality for users on HTTPS pages. CWE-311 (Missing Encryption of Sensitive Data) and OWASP A02 (Cryptographic Failures) both apply when application resources are loaded over unencrypted HTTP, exposing data to network-level interception even on nominally HTTPS pages.

## Severity rationale

Medium because mixed content exposes specific resource loads to network interception on HTTPS pages, and `upgrade-insecure-requests` is a low-cost directive that eliminates this entire class of vulnerability as a safety net.

## Remediation

Add `upgrade-insecure-requests` as a directive in your existing CSP header. It requires no configuration — the browser handles all HTTP-to-HTTPS upgrades automatically.

```
Content-Security-Policy: upgrade-insecure-requests; default-src 'self'; script-src 'nonce-{perRequest}' 'strict-dynamic'
```

This directive is additive and safe to deploy immediately alongside an existing policy. It does not affect navigation (`<a href>` clicks) — only subresource loads (`<img>`, `<script>`, `<link>`, `<iframe>`, etc.). Fix the root-cause `http://` URLs as a follow-up — `upgrade-insecure-requests` is a safety net, not a substitute for correct URLs.

## Detection

- **ID:** `upgrade-insecure-requests`
- **Severity:** `medium`
- **What to look for:** Parse the CSP header for the `upgrade-insecure-requests` directive. This directive auto-upgrades HTTP URLs to HTTPS within the page, preventing mixed content issues without requiring code changes. Check the full CSP string.
- **Pass criteria:** CSP includes `upgrade-insecure-requests` — at least 1 occurrence required. Count the total CSP directives and report: "upgrade-insecure-requests directive present in CSP (X total directives)."
- **Fail criteria:** CSP does not include `upgrade-insecure-requests`.
- **Skip (N/A) when:** No CSP configured (cannot add directives to a nonexistent policy).
- **Detail on fail:** `"CSP does not include upgrade-insecure-requests — HTTP resources on HTTPS pages will be blocked or trigger mixed content warnings"` or `"No upgrade-insecure-requests directive — legacy HTTP URLs in content will not be auto-upgraded"`
- **Remediation:** `upgrade-insecure-requests` automatically rewrites `http://` URLs to `https://` for all resources on the page. This is a safety net for legacy content or user-generated content that may contain HTTP URLs:

  ```
  Content-Security-Policy: upgrade-insecure-requests; default-src 'self'
  ```

  This is a safe directive to add — it only affects resource loading, not navigation. Add it to your existing CSP.

---

## External references

- cwe CWE-311
- owasp A02

Taxons: injection-and-input-trust, cryptography-and-secrets

HTML version: https://auditbuffet.com/patterns/ab-002447