upgrade-insecure-requests
upgrade-insecure-requests
upgrade-insecure-requests
The upgrade-insecure-requests directive instructs the browser to upgrade HTTP requests to HTTPS before fetching, helping to secure communication by avoiding mixed content.
Recommended Values
upgrade-insecure-requests
Instructs the browser to upgrade HTTP requests to HTTPS before fetching
Instructs the browser to upgrade HTTP requests to HTTPS before fetching
Explore detailed value definitions
Tips & Tricks
This directive is particularly useful when migrating large sites from HTTP to HTTPS, as it reduces the need to update all resource links manually.
While this directive upgrades requests, it doesn't guarantee that the upgraded requests will succeed. The server must support HTTPS for the resources.
Examples
Upgrade all insecure requests to HTTPS
Content-Security-Policy: upgrade-insecure-requests;Allowed
<img src='https://example.com/image.jpg'>Blocked
<img src='http://example.com/image.jpg'> <!-- Will be upgraded to HTTPS -->
Frequently Asked Questions
What is the upgrade-insecure-requests directive?
The upgrade-insecure-requests directive instructs browsers to upgrade HTTP requests to HTTPS before fetching them. This helps sites transition from HTTP to HTTPS by automatically upgrading insecure resource requests to secure ones, without having to update all URLs in the codebase manually.
How it works
When this directive is present, the browser will modify any HTTP URLs before requests are made, changing them from http:// to https://. This applies to all resource types including images, scripts, styles, and more.
When should I use upgrade-insecure-requests?
You should use this directive when migrating a site from HTTP to HTTPS, especially if you have a large number of HTTP URLs in your content that need to be upgraded. It's particularly useful for sites with user-generated content or third-party resources that might still use HTTP URLs.
Important Note
This directive only upgrades requests - it doesn't guarantee they will succeed. The remote server must support HTTPS for the upgraded requests to work.
How does it differ from block-all-mixed-content?
While upgrade-insecure-requests attempts to upgrade HTTP requests to HTTPS, block-all-mixed-content simply blocks any HTTP requests without trying to upgrade them. upgrade-insecure-requests is more permissive and better suited for transitioning to HTTPS, while block-all-mixed-content is stricter and better for sites that should never load insecure content.
Does upgrade-insecure-requests affect all resources?
Yes, the directive affects all outbound HTTP requests from your page, including images, scripts, styles, frames, and fetch requests. However, it only upgrades requests that use the HTTP scheme - it doesn't affect relative URLs or already-secure HTTPS URLs.
Best Practice
While upgrade-insecure-requests is helpful during HTTPS migration, the long-term goal should be to update all source URLs to HTTPS directly in your codebase.
Need to monitor CSP violations and maintain it easily?
Set up a reporting endpoint to monitor Content Security Policy violations in real-time to build and maintain your CSP easily.
Set up your endpoint now