Hash Source

Expanded Definition

A hash source is a policy mechanism used to permit a specific inline script or style only when its content exactly matches a precomputed cryptographic digest. In practice, this makes it a narrower control than allowing all inline code, because the browser evaluates the content against the declared hash before execution. Within web application security, hash sources are usually discussed as part of Content Security Policy, where they help reduce exposure to cross-site scripting by avoiding broad exceptions. Authoritative guidance from the NIST Cybersecurity Framework 2.0 supports the wider governance principle behind this approach: access and execution should be constrained to what is explicitly authorised.

Definitions are mostly consistent across security communities, but usage in the industry is still evolving in modern build pipelines, especially where frameworks inject inline code dynamically. Hash sources are not a general approval for inline content, and they are not interchangeable with nonce-based policies. The operational distinction matters because a hash source binds permission to a fixed payload, while a nonce binds permission to a response-specific value. The most common misapplication is treating a hash source as a reusable wildcard, which occurs when teams change inline code without updating the policy hash.

Examples and Use Cases

Implementing hash sources rigorously often introduces release coordination overhead, requiring teams to weigh tighter execution control against the cost of rebuilding and republishing policy values whenever inline content changes.

• A product team hashes a small inline bootstrap script that must run on every page load, then updates the policy whenever that script changes.
• A security team uses hash sources to allow a specific inline style block while blocking all other inline styles, reducing the need for broad OWASP-style hardening exceptions.
• A build pipeline computes the digest during release so the deployed Content Security Policy and the shipped HTML stay aligned.
• A platform team uses hash sources for a legacy page that cannot easily remove inline code, as an interim control while refactoring toward external files.

Where organisations follow the guidance in Content Security Policy Level 3, hash sources are especially useful for preserving function without opening unrestricted inline execution.

Why It Matters for Security Teams

Hash sources matter because they let security teams approve only the exact code they expect, which is a much stronger posture than allowing all inline execution. That precision helps reduce the attack surface for script injection, but it also creates change-management obligations: if the inline content changes, the hash must change too, or the application will fail closed. In environments that use Content Security Policy as a defense-in-depth layer, hash sources support a more deterministic review model than ad hoc exceptions.

This becomes particularly relevant when application teams need to satisfy secure coding expectations in frameworks such as the OWASP Content Security Policy Cheat Sheet, because the control is only effective when hashes are generated and maintained accurately. Security reviewers should also understand the operational tradeoff with build tooling, deployment frequency, and content generation patterns. Organisations typically encounter broken pages, blocked functionality, or emergency policy relaxations only after a release changes inline content, at which point hash source management becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why is DevOps such a significant source of NHI risk?
• Why is hardcoding credentials into source code so dangerous?
• What is the difference between source control leakage and SharePoint secret exposure?
• Why do secrets in source code create NHI governance problems?