Content Security Policy (CSP) is a security standard implemented as an HTTP response header that allows web application developers to declare which sources of content (scripts, styles, images, fonts, frames, etc.) are permitted to load and execute in users' browsers. By defining an allowlist of trusted origins and blocking everything else, CSP acts as a powerful defense-in-depth layer against cross-site scripting (XSS), code injection, and UI manipulation attacks.

In DeFi and Web3 applications, CSP is particularly important because the consequences of frontend code injection extend beyond traditional data theft. A malicious script running in a DeFi user's browser can manipulate transaction data before signing, request unlimited token approvals, or redirect wallet interactions to attacker-controlled contracts. The Bybit hack of February 2025 demonstrated how a single compromised JavaScript file in a frontend could lead to $1.5 billion in losses.

How CSP Works

CSP is delivered as an HTTP header (Content-Security-Policy) with each page response from the web server. The header contains a set of directives, each specifying allowed sources for a particular type of resource:

1Content-Security-Policy: 
2  default-src 'self'; 
3  script-src 'self' https://cdn.trusted.com; 
4  style-src 'self' 'unsafe-inline'; 
5  connect-src 'self' https://api.protocol.io https://rpc.chain.com;
6  img-src 'self' data: https:;
7  frame-ancestors 'none';

Key directives for DeFi applications include:

• script-src — Controls which JavaScript can execute. Blocking inline scripts and restricting to specific origins prevents most XSS attacks.
• connect-src — Controls which URLs the application can connect to via fetch, XMLHttpRequest, or WebSocket. Critical for restricting RPC endpoint connections.
• frame-ancestors — Prevents the application from being embedded in iframes, blocking clickjacking attacks.
• default-src — Fallback policy for any resource type not explicitly covered by other directives.

When a browser encounters a resource that violates the CSP policy, it blocks the resource from loading or executing and optionally reports the violation to a specified endpoint via the report-uri or report-to directive.

CSP for DeFi Frontend Security

DeFi frontends face unique security challenges that CSP directly addresses:

Script injection prevention is the primary benefit. If an attacker manages to inject a <script> tag into the page (via XSS, CDN compromise, or supply chain attack), a strict CSP that blocks inline scripts and restricts script sources will prevent the injected code from executing. This would have mitigated the impact of attacks like the Bybit frontend compromise, where malicious JavaScript was served from a compromised hosting infrastructure.

RPC endpoint restriction using connect-src ensures the frontend can only communicate with authorized blockchain RPC endpoints. Without this, injected code could redirect transaction submissions to attacker-controlled nodes that selectively censor or front-run transactions.

Wallet interaction protection through strict script sources prevents malicious code from hijacking wallet provider objects (e.g., window.ethereum) or intercepting signing requests. Combined with Subresource Integrity (SRI), CSP ensures that only verified, unmodified scripts interact with user wallets.

Implementation Challenges

Implementing strict CSP in DeFi applications requires careful planning:

Inline scripts and styles are common in modern JavaScript frameworks (React, Next.js) and must be handled through nonces ('nonce-<random>') or hashes rather than the insecure 'unsafe-inline' directive. Build pipelines need to generate unique nonces per request or compute hashes of inline content.

Third-party integrations such as analytics, wallet providers, and RPC services require explicit allowlisting. Each additional allowed origin increases the attack surface, so teams should minimize third-party dependencies and regularly audit allowed sources.

Web3-specific considerations include allowing connections to multiple RPC endpoints, IPFS gateways, and decentralized storage services. The connect-src directive must balance security with the decentralized nature of blockchain interactions.

Monitoring and Enforcement

CSP supports a report-only mode (Content-Security-Policy-Report-Only) that logs violations without blocking resources. This allows teams to test policies in production before enforcing them. Violation reports can be collected and analyzed to identify both misconfigurations (legitimate resources being blocked) and potential attacks (unexpected scripts or connections being attempted).

For DeFi protocols, CSP violation reports can serve as an early warning system for frontend compromise. A sudden increase in violations for unknown script sources could indicate a CDN compromise or supply chain attack in progress, enabling rapid incident response before significant user funds are lost.