iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Set security headers at the web server, hosting platform, or CDN that serves your Angular app—not in an Angular component. Start with a Content Security Policy (CSP) in report-only mode, check which resources your app actually uses, then enforce a policy that fits its deployment. Angular’s Security documentation calls CSP “a defense-in-depth technique to prevent XSS”; it is not a substitute for secure coding.
Where Angular security headers belong
Security headers are HTTP response headers. Configure them in the layer that returns your app’s HTML: for example, your web server, hosting provider, or CDN. Angular can supply a CSP nonce to its runtime, but it does not configure the response headers for you.
Send the policy on all relevant responses, especially the document responses that load the application. A policy delivered in an HTTP header supports the full CSP feature set. A <meta> policy is a constrained fallback when you cannot control response headers; directives such as frame-ancestors, report-uri, and sandbox are ignored in a meta policy. See Angular’s security guidance and the OWASP Content Security Policy Cheat Sheet.
Build a CSP around the app’s actual resources
Angular documents this minimal policy as a starting point for a new application:
#1 Best Overall
default-src 'self'; style-src 'self' 'nonce-randomNonceGoesHere'; script-src 'self' 'nonce-randomNonceGoesHere';It is not a universal production policy. Replace the example nonce with a securely generated value where you use nonces, and inventory the resources your app needs before enforcing the policy. Third-party services, fonts, images, API connections, and other application features can require additional directives or trusted sources. Keep source lists as narrow as practical; do not add broad allowances simply to make violations disappear.
Choose nonce or hash according to delivery
| Approach | Best fit | What to account for |
|---|---|---|
| Nonce | HTML generated dynamically at request time | Generate an unpredictable nonce for each response and put the matching value in the CSP header and authorized HTML elements. A cached HTML document must not reuse a nonce across responses. |
| Hash | Stable, build-time inline content, including static delivery | The hash must match the exact inline content. If the content changes, the corresponding hash must be updated. |
MDN describes nonces as suitable for dynamic content and hashes as suitable for static content. The right choice depends on how your HTML and scripts are produced and delivered; see MDN’s CSP guide.
Pass a nonce safely to Angular
For server-rendered or otherwise dynamically generated HTML, Angular supports two ways to provide the nonce used by its runtime:
ngCspNonce: put the request’s nonce on the root application element inindex.html.CSP_NONCE: provide the nonce through Angular’s injection token.
Whichever method you use, the value supplied to Angular must match the nonce in that response’s CSP header. Generate a fresh, cryptographically unpredictable nonce for each response. If a CDN caches HTML containing a nonce, it can accidentally serve the same nonce-bearing document to multiple responses. Generate the nonce at the delivery edge or use a delivery architecture that transforms cached HTML for each response.
Account for static hosting and Angular’s autoCsp
Static hosts generally serve build output rather than generating new HTML for each request, so embedding a fixed nonce in the page is not a safe substitute for per-response nonce generation. Angular’s security.autoCsp build option can add hashes for inline scripts, but it covers scripts only; styles still need an appropriate policy.
Angular notes that a meta policy cannot enforce every directive. If you combine autoCsp with a CSP response header, follow Angular’s documented interaction rules rather than independently adding conflicting script-src or default-src directives. Review Angular’s security documentation for the current configuration details.
Roll out the policy without blocking the app
- Inventory resources. Identify scripts, styles, images, fonts, API connections, and third-party integrations the application needs, including resources loaded in less-common user journeys.
- Draft a narrow policy. Begin with Angular’s example as a baseline, then add only the sources and directives justified by that inventory. Prefer nonces or hashes for inline code over
'unsafe-inline'; refactor inline event handlers and uses ofeval()where possible. - Send it in report-only mode. Return the proposed policy as
Content-Security-Policy-Report-Only. The browser reports violations without blocking the resources, giving you a chance to find legitimate dependencies and unintended inline code. - Review and correct reports. Investigate each violation. Add a source only when the app genuinely needs it; otherwise change the application or remove the dependency. Reporting requires a configured reporting endpoint. MDN prefers
report-toover deprecatedreport-uri, but browser support for reporting features is incomplete, so check compatibility with your target browsers. - Enforce and keep monitoring. After legitimate violations are addressed, return the policy as
Content-Security-Policy. Continue reviewing reports and retest when app code, dependencies, or deployment configuration changes.
Report-only mode is an observation stage, not enforcement: it will not stop a resource from loading. OWASP recommends it as a precursor to enforcement and emphasizes that CSP is one defense layer, not a replacement for secure development practices. See MDN’s CSP guide and the OWASP cheat sheet.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsConsider Trusted Types for additional XSS protection
Angular recommends Trusted Types enforcement as an additional defense, where the browsers you support implement it. Add only the Angular policies required by your application’s features:
Best Value
angularfor Angular’s security-reviewed code.angular#bundlerwhen using Angular CLI lazy chunk bundling.angular#unsafe-bypasswhen usingDomSanitizerbypass APIs.angular#unsafe-jitwhen using Just-in-Time compilation.angular#unsafe-upgradefor AngularJS hybrid applications.
These policy names and their use cases are documented in Angular’s security guidance. Do not enable policies for features the app does not use.
Add headers for other browser-facing protections
These headers address different risks; they do not replace CSP or guarantee that an application is secure.
| Header | Purpose | Practical note |
|---|---|---|
X-Content-Type-Options: nosniff |
Limits MIME-type sniffing. | OWASP recommends setting it explicitly. |
Referrer-Policy: strict-origin-when-cross-origin |
Controls how much referrer information browsers send. | OWASP identifies this as the modern-browser default and recommends setting a policy explicitly. |
CSP frame-ancestors |
Controls which sites may embed the application in a frame. | OWASP prefers this CSP directive where supported; it must be delivered in an HTTP header. |
X-Frame-Options |
Provides a more limited framing control. | It is an alternative with a narrower role than CSP frame-ancestors. |
OWASP advises against setting X-XSS-Protection, including explicitly disabling it with X-XSS-Protection: 0. Consult the OWASP HTTP Headers Cheat Sheet for its guidance on these additional headers.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
