Web application security is a constant challenge for any organization that handles critical data. One of the most recurrent attack vectors is malicious script injection (XSS), which can compromise user sessions, steal sensitive information, or redirect to fraudulent sites. To mitigate this risk, one of the most effective tools is the Content Security Policy (CSP), in particular the script-src directive. In this article, we'll explore how to handle scripts allowed on a page using hashes, nonces, and strict-dynamic, providing a practical and professional view for developers and security managers.
Before delving deeper, it is important to understand the context. CSP acts as an additional layer of defense that tells the browser which are the sources and contents of scripts that the application has explicitly authorized. The script-src directive covers both external scripts (loaded from a URL) and inline scripts and event handlers in HTML attributes. Without a proper policy, any script injected by an attacker could be executed. Therefore, in environments where we develop custom applications, the implementation of CSPs becomes an essential requirement to guarantee the cybersecurity of the final product.
The simplest approach is to use source whitelists (script-src 'self' https://cdn.ejemplo.com). However, this solution has significant limitations. If we allow a full source, we are trusting all files served from there, including those that could be compromised. While we may restrict to specific routes, in practice many CDNs and third-party services require broad access. In addition, whitelists do not authorize inline scripts; for this we need hashes or nonces. In our work with customers migrating to AWS and Azure cloud services, we've seen how a misconfigured policy can block legitimate functionality or open security gaps.
Hashes are cryptographic fingerprints of the exact content of an inline script. They work well when the script is static, such as a build-time version of the application. The browser calculates the hash and compares it to the hash that appears in the CSP header. If they match, it is executed. This method is robust, but fails when the script changes on a per-user or per-request basis, for example, by including a session ID or custom configuration. Also, any slight variation (spaces, line breaks) invalidates the hash. Therefore, in scenarios where the content is dynamic, nonces are more appropriate.
A nonce is a random token that the server generates for each HTTP response. It is inserted in both the CSP header and the nonce attribute of the <script> tag. The browser checks that they match, regardless of the content of the script. This allows variable data to be injected without the need to recalculate hashes. The condition is that the nonce is cryptographically random and unique on request; otherwise, an attacker could predict it and bypass protection. Nonces are ideal for applications that generate fresh HTML on every request (such as those that integrate artificial intelligence or AI agents to personalize the user experience). However, they are not suitable for cached pages or static sites, because the nonce would be repeated, losing its value. In those cases, hashes are the best alternative.
When an authorized script needs to load other scripts dynamically (for example, an analytics SDK or chat widget), a problem arises: the child script has no nonce or hash. The strict-dynamic directive resolves this by propagating trust from the original script to everyone it loads using document.createElement('script'). In this way, we avoid having to list each third-party source, reducing the attack surface. However, the original script must be authorized by nonce or hash. It is crucial to audit that script, as if it is vulnerable or compromised, it can execute malicious code. At Q2BSTUDIO, when developing custom software, we apply strict-dynamic to integrate external libraries minimizing risks, always combined with rigorous pentesting to detect possible leakage points.
Another aspect to consider is inline event handlers such as onclick or onload. These are also controlled by script-src. If we use nonces or hashes, we can't apply them directly to those attributes. The solution is to migrate the logic to <script> blocks with addEventListener, or separate the rules using script-src-elem (for script tags) and script-src-attr (for handlers). This separation allows CSP to be adopted gradually, without having to choose between unsafe-inline or blocking everything. Business intelligence service projects that use Power BI, for example, typically include integration scripts; Segmenting policies helps maintain security without breaking functionality.
Finally, let's remember that CSP is not a magic bullet. It does not protect against internal vulnerabilities such as open redirects, where a trusted script redirects to a malicious site based on URL parameters. Security must be addressed in multiple layers: input validation, output sanitization, and well-designed CSP policies. At Q2BSTUDIO we offer cybersecurity services and CSP implementation consulting, helping companies secure their web applications while leveraging technologies such as enterprise AI and AI agents securely. In addition, we integrate these practices into our process automation processes to ensure that safety goes hand in hand with efficiency.
In short, scripting with CSP is a discipline that requires understanding when to use each technique: hashes for static content, nonces for dynamic content per session, and strict-dynamic for dynamic third-party loads. The choice depends on the architecture of the application and the deployment model. Implementing a robust policy not only prevents XSS attacks, but also builds user trust and complies with regulatory compliance standards. If you want to strengthen the security of your applications or need guidance in the adoption of these practices, at Q2BSTUDIO we have an expert team in development, cloud and cybersecurity ready to accompany you.
