Directive
img-src tells the browser which image sources are allowed.
Content Security Policy (CSP) is one of the browser's most versatile security controls. It can restrict scripts, styles, connections, framing, form destinations, embedded objects, and more.
This guide is not a CSP generator. It is designed to help you understand what an existing policy permits, how its directives interact, and where security-relevant gaps may exist.
A policy is a series of semicolon-separated directives. Most directives are followed by one or more source expressions that define what is allowed, but not every directive takes a source expression. Some directives are standalone instructions to the browser.
Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; upgrade-insecure-requests;
img-src tells the browser which image sources are allowed.
'self' or data: defines where the browser may load that content from.
upgrade-insecure-requests takes no source expression. Its presence alone instructs the browser to upgrade eligible insecure requests.
These directives explain most real-world CSP reviews. You do not need every directive in the specification memorized to understand what a policy is trying to do.
default-srcProvides the baseline source list for several resource-loading directives that are not explicitly present.
script-srcControls where scripts may load from and, depending on the policy, whether inline or dynamically evaluated JavaScript may execute.
style-srcControls where CSS may load from and whether inline styling is permitted.
img-srcControls permitted image sources, including hosts, schemes, and sources such as data:.
connect-srcControls destinations used by fetch(), XMLHttpRequest, WebSockets, EventSource, and similar browser APIs.
font-srcControls where web fonts may be loaded from.
frame-srcControls which sources this application may load into frames such as <iframe>. Think: What can I frame?
frame-ancestorsControls which parent sites may embed the current page. Think: Who can frame me? This is the framing control commonly used to defend against clickjacking.
object-srcControls plugin-style content such as <object> and <embed>. Modern applications often set this to 'none'.
base-uriRestricts which URLs may be used by the document's <base> element.
form-actionControls where HTML forms may submit data. This directive does not inherit from default-src.
upgrade-insecure-requestsA standalone directive with no source expression. It tells the browser to upgrade eligible HTTP resource requests to HTTPS. Useful for transport hygiene, but by itself it does not restrict script sources, framing, connections, form destinations, or other content.
frame-src and frame-ancestors are related, but they are not opposites of the same directive. One controls what the current page may load in a frame; the other controls which parent pages may frame the current page.The directive tells you what behavior is being controlled. The source expression tells you where that behavior is permitted. Some expressions are intentionally broad, and some can materially weaken the protection a directive would otherwise provide.
Color is a review aid, not a verdict. Green does not automatically mean safe, and amber or red still need to be interpreted in the directive and application context where the expression appears.
'self'Allow the same origin as the protected page.
'none'Allow nothing for that directive.
*Allow a very broad set of sources. The exact effect depends on the directive, but a wildcard often expands trust far beyond what the application actually needs.
https://cdn.example.comAllow a specific host source.
https:Allow sources broadly over HTTPS rather than limiting trust to specific hosts. Encryption does not make every HTTPS origin trustworthy.
data:Allow data: URLs. Common and often reasonable for images, but more concerning when used with directives that can load active content.
blob:Allow browser-generated blob URLs, often used for workers, media, or generated files. Review where it is permitted and whether the application requires it.
'nonce-...'Allow inline content carrying a matching unpredictable, per-response nonce.
'sha256-...'Allow specific inline content whose cryptographic hash matches the policy.
'unsafe-inline'Allows inline script or style behavior. In script-src, this can remove a major barrier CSP would otherwise place in front of injected JavaScript.
'unsafe-eval'Allows string-to-code execution mechanisms such as eval(), weakening CSP's ability to constrain dynamically generated JavaScript.
default-src does not cover everythingDirectives such as frame-ancestors, form-action, and base-uri need their own rules when they matter.
Wildcards, scheme-wide sources, and large host patterns may permit far more content than the application actually needs.
'unsafe-inline' and 'unsafe-eval' can undermine the controls that make CSP useful against script injection.
Every CDN, analytics host, and external script source expands the set of systems the browser is being told to trust.
Content-Security-Policy: script-src * 'unsafe-inline' 'unsafe-eval'That is technically a CSP. It is also an example of why checking for the header alone tells you very little.
Content-Security-Policy: upgrade-insecure-requests;upgrade-insecure-requests is also a valid CSP directive, but a policy containing only that directive is not meaningfully restricting content sources. It upgrades eligible insecure requests; it does not provide the source restrictions people usually associate with CSP.
default-src 'self';
script-src 'self' https://cdn.example.com;
img-src 'self' data:;
connect-src 'self' https://api.example.com;
object-src 'none';
base-uri 'self';
form-action 'self';
frame-ancestors 'none';
upgrade-insecure-requests;default-srcUse the same origin as the fallback for supported resource types.script-srcAllow JavaScript from the application and the approved CDN.img-srcAllow same-origin images and embedded data: images.connect-srcAllow browser-side connections to the application and its API.object-srcDo not allow plugin-style embedded objects.base-uriRestrict document base URLs to the same origin.form-actionRestrict form submissions to the same origin.frame-ancestorsDo not allow any site to frame the application.upgrade-insecure-requestsUpgrade eligible insecure resource requests to HTTPS. No source expression is required.data: URLs, allows browser-side connections to one API, blocks plugin-style objects, keeps base URLs and form submissions on the same origin, prevents other sites from framing the application, and upgrades eligible insecure resource requests to HTTPS.
A strong policy can make exploitation harder and reduce the impact of some client-side vulnerabilities, especially Cross-Site Scripting (XSS). It does not make the underlying flaw disappear.
Restrict script execution and where executable content may come from.
Use frame-ancestors to control which sites may frame the application.
Use connect-src to constrain browser-side connections to approved destinations.
Use form-action to restrict where forms may send data.
A Content Security Policy can look restrictive at a glance and still leave important gaps. Start by checking the headers your application currently returns.