Content Security Policy for MENA portals: a rollout guide
Choose nonces or hashes, test Arabic and English journeys, and move from report-only to enforcement with a controlled rollback.
A checkout page works in English but loses its Arabic font after a security-header change. A support widget loads on the dashboard, then fails on the payment route. The team fixes both by allowing every HTTPS source, and the policy becomes much less useful.
Content Security Policy (CSP) deserves a release plan. For a MENA product with Arabic and English interfaces, separate regional deployments and external service providers, the difficult work is deciding which browser capabilities each journey needs and proving that the deployed policy matches that decision.
This guide proposes a rollout for a hypothetical merchant portal operated separately in Saudi Arabia and the UAE. It is an engineering design, not a tested product implementation or a claim of regulatory compliance. The country labels identify deployments; they do not imply that either country mandates the policy below.
Cover: original SultanByte artwork showing the progression from observed violations to controlled enforcement.
Start with a dependency record, not a copied header
Choose a bounded route family, such as merchant onboarding. List its scripts, stylesheets, fonts, API connections and embedded frames. Include the dependencies that appear only after an error, a language change or a payment-provider handoff. Record the responsible owner and whether the dependency is essential to that route.
Keep the Saudi and UAE records separate where the deployed integrations differ. In this example, each deployment has its own approved payment configuration. That is a product assumption, not a statement about a named provider's requirements. Verify each provider's current integration documentation and your actual browser traffic before adding an origin.
Also distinguish application code from a tag manager. OWASP's third-party JavaScript guidance describes how tags can change outside the application's release process and access information in the page. A vendor being commercially approved does not make every script it can introduce appropriate for an authenticated portal.
For this design, exclude marketing tags from payment and account-administration routes unless a documented need survives review. Give any exception an owner and removal condition. Do not expand the whole site's permissions to accommodate one optional widget.
Choose how scripts earn permission
OWASP recommends a strict CSP based on nonces or hashes rather than relying solely on host allowlists. CSP is an additional defence against exploitation; it does not replace contextual output encoding, safe DOM operations or other XSS prevention work.
Use the rendering model to choose the first implementation:
- For dynamically generated HTML, consider a fresh cryptographic nonce attached only to scripts the application deliberately authorizes.
- For stable, cacheable HTML, consider hashes of the exact approved inline script contents, generated as part of the build.
The CSP specification's nonce requirements call for a unique value each time a policy is transmitted, recommend at least 128 bits before encoding, and recommend a cryptographically secure generator. This is not a release identifier or a value stored in configuration.
Make the HTML and its policy one delivery unit. In the proposed nonce implementation, inspect the CDN, reverse proxy and server-rendering path together. A fresh header paired with cached HTML can leave legitimate scripts without a matching nonce. Reusing a cached nonce-bearing response is not the per-transmission uniqueness model described by the specification.
For a hash-based implementation, compute hashes from the final emitted script contents. Whitespace changes matter, as OWASP's hash guidance explains. Treat HTML transformation at the edge as part of the build-and-delivery contract, not an unrelated optimization.
Do not add nonces to every script found by a generic HTML-rewriting pass. OWASP warns that this can authorize attacker-injected script elements too. The template or framework integration must know which scripts it intends to trust.
Review what trusted loaders can do
A strict policy often uses strict-dynamic. The CSP specification explains that this allows trusted scripts to load further scripts through non-parser-inserted elements. In supporting browsers, host and scheme sources, including self, are ignored for that script-loading policy.
That changes the review question. A short hostname list is not a complete description of what an authorized loader may execute. Inspect how loaders construct script URLs and whether user-controlled data can influence them.
For the merchant portal, require a specific decision before authorizing a tag manager or broad plugin loader. Identify who can modify its configuration, how changes are approved and how the application owner learns about a new dependency. A nonce authorizes execution; it does not certify the script's behaviour.
Where a versioned external asset can be pinned, evaluate Subresource Integrity separately. The W3C SRI specification describes checking received bytes against expected integrity metadata and refusing execution when verification fails. Cross-origin use requires the appropriate CORS arrangement. A CSP permission and an integrity check answer different questions: whether a resource may run, and whether its bytes match the expected content.
For this proposed deployment, a deliberately changing vendor script needs an explicit change contract. Do not pin yesterday's bytes and assume tomorrow's vendor update will keep working.
Original infographic: SultanByte. Proposed engineering framework informed by W3C CSP and Reporting API specifications, OWASP and MDN documentation, October 2026. These are rollout decisions, not measured results.
Keep resource permissions distinct
Do not solve a font failure by loosening script permissions. The MDN directive reference separates font-src, style-src, connect-src and frame-src. It also distinguishes frame-ancestors, which controls who may embed your page, from the frames your page loads.
For an Arabic-English portal, trace both the stylesheet request and the font-file request. Test the Arabic interface after a cold load, not only on a development machine that already has assets cached. SultanByte's Arabic web-font guide covers the separate rendering and fallback questions.
Record form destinations explicitly. form-action and frame-ancestors are not covered by default-src fallback. A restrictive default therefore does not finish the policy. Decide which routes may be framed and which form submissions are permitted, then test the actual integration.
Avoid treating browser connection permissions as a data-residency certificate. The policy controls browser behaviour within its defined scope; the portal still needs separate review of service processing, storage and onward handling. This guide does not determine those legal or contractual obligations.
Observe before enforcing, but test blocking too
The CSP report-only header monitors a policy without enforcing it. It can run alongside an existing enforced policy. Deliver it as an HTTP response header; report-only is not supported through a CSP meta element.
For this rollout, label every candidate policy with an internal version in the release record. Deploy it to the selected routes and exercise both languages, permitted user roles, error screens and provider-return paths. Assign each observed violation to an expected dependency, a defect or an unresolved finding. Do not automatically add every reported origin to an allowlist.
A clean report stream is not sufficient evidence. The Reporting API specification explicitly describes delivery as best effort, without a guarantee that reports arrive. Use reports to find problems, then verify behaviour directly in the supported browsers.
Run the candidate in enforcement mode in a controlled environment before releasing it to customers. Confirm that intended scripts execute and deliberately unapproved test scripts do not. Repeat critical journeys through the real header-delivery path. A report-only rehearsal cannot demonstrate that payment completion survives blocking.
Treat the collector as an untrusted intake
CSP reports are diagnostic input, not a trusted event ledger. The specification warns that report content can be attacker-controlled. Escape it when rendering dashboards and apply bounded parsing, payload limits and abuse controls at intake.
The proposed collector should retain only the fields needed to identify policy version, route class, directive and failure category. Review URLs and optional script samples before sending them to an external service. Redaction after collection does not undo a disclosure that already occurred during delivery.
Keep separate collector configurations for the hypothetical Saudi and UAE deployments until their telemetry handling has been approved. Decide the destination, access controls and retention period for each. Those are review requirements for this architecture, not prescribed national retention periods.
Configure and test the reporting mechanism on the browser versions you support. Where compatibility requires a legacy reporting path, document it instead of assuming every browser sends the same payload through the same API.
Release with a policy-specific rollback
Keep a release record that connects the policy to the application version, route family, deployment, approved dependencies and test evidence. The proposed acceptance checks are:
- Load Arabic and English journeys with empty caches, including error pages and provider returns. Confirm essential assets and actions work.
- Inspect the delivered headers at the public edge. Confirm the intended mode and identify any additional policy added by infrastructure.
- For nonce-based pages, compare independently delivered responses and verify header-to-element agreement. Review the generation and caching implementation as well as the samples.
- For hash-based pages, change a test script's emitted contents. Confirm the build updates its approved hash and an intentionally mismatched version is blocked.
- Trigger a controlled violation. Inspect browser behaviour and collector handling separately; missing telemetry must not be treated as successful enforcement.
- Rehearse restoring the last approved policy with the matching application release. Repeat the critical journey after rollback.
Multiple enforced policies do not combine into a more permissive union: each policy must be satisfied. Adding a second header is therefore not a reliable way to relax a restriction imposed by the first. Document which layer owns each header and how an emergency change reaches it.
For the CTO, the useful deliverable is a versioned dependency decision and evidence that essential journeys survive enforcement. For the engineer on call, it is an exact rollback procedure with a named approver. Start with one route family, resolve its exceptions, and widen coverage only after the deployed result is understood.
