76% had no CSP and 64% could be loaded inside a frame controlled by another site. These are the two most striking findings from a review of DeFi protocol websites published on DEV Community. The analysis examined the responses a typical browser received; it did not attempt to exploit the sites or connect to their wallets.
The distinction matters: the figures describe the visible configuration of the pages analyzed, not incidents or losses. Even so, they point to web defenses that may be relevant when an interface invites users to sign transactions with a wallet.
What the review measured
The team started with the DefiLlama protocols that had a website—about 4,000 domains—and randomly selected 1,000. Of those, 896 responded; 39 blocked the automated checks and 65 did not respond. The published percentages are based on those 896 sites.
The check was passive: the homepage was loaded and response headers, cookie indicators, HTTPS, third-party scripts, and broken links were reviewed. There was no login, wallet connection, form submission, or search for hidden files. Project names and individual results were not published either.
In addition to the lack of CSP and framing protection, the team found that 35% had no HSTS, 27% loaded third-party scripts without Subresource Integrity (SRI), 6% had cookies without the Secure or HttpOnly attributes, and 5% had broken links on the homepage.
The main limitation is where the test was conducted. For many projects, the homepage is an informational website, while the application containing the button to connect a wallet lives at another address. For this reason, the analysis itself presents its findings as a signal to investigate, not as proof that people using those projects are at risk.
An interface can be part of the attack surface
The report contrasts the measures dedicated to protecting smart contracts with the attention paid to the websites users rely on to interact with them. As background, it cites the December 2021 BadgerDAO incident, which involved losses of about $120 million, where a script injected into the interface requested token approvals. It also mentions the December 2023 Ledger Connect Kit incident: a poisoned version of a widely used interface library turned dApps into tools for draining wallets.
CSP, or Content Security Policy, lets a site limit the resources a browser can load and the destinations to which it can send data. According to the analysis, it acts as a second barrier if a script has already been injected: it can restrict where code runs and where data is transmitted. It does not prevent every injection on its own, but an explicit policy limits what that code could do.
Framing poses another risk. OWASP's testing guide describes clickjacking as a deception in which a page hides the target application inside an iframe and makes a person click elements other than the ones they think they are using. For an interface that requests signatures, the DEV Community team suggests that an attacker could align an approval button beneath another one promising, for example, to claim a reward.
The loaded page is still authentic, but the person may interact with it without realizing what action they are taking. OWASP also warns that some CSRF defenses can be bypassed in this scenario. Therefore, it is not enough for the smart contract to be correct if the interface leading to a signature can be presented deceptively.
The comparison shows no advantage in the two key defenses
For comparison, the team also reviewed 1,000 ordinary websites; 571 responded. DeFi sites performed better on three measures: HSTS was missing on 35% versus 61%; cookies lacked Secure or HttpOnly on 6% versus 26%; and 27% had third-party scripts without SRI, compared with 64%.
But the comparison differs for the protections most closely associated with interfaces that request signatures. 64% of DeFi sites could be framed by another website, compared with 58% of ordinary sites. And 76% lacked CSP, compared with 79% in the other sample. In other words, the review found no DeFi advantage in these two controls; nor does it prove that the compared websites offer the same type of interaction or risk.
Simple configuration, but with compatibility decisions
The team proposes three measures: a CSP with an explicit list of permitted scripts and the frame-ancestors 'none' directive; SRI for every third-party script—or hosting them on the site's own infrastructure—and HSTS. According to the team, these are configuration fixes, not code changes, and all three can be deployed in an afternoon.
The frame-ancestors directive lets you specify which sites can embed a page using elements such as iframe. OWASP recommends using it as a server-side defense against clickjacking. The 'none' value prevents other sites from framing it; for a product that needs to allow legitimate frames, the policy must reflect that need rather than block them indiscriminately.
CSP also requires deciding which resources the application actually needs. An explicit list of permitted scripts can limit the execution of unauthorized code, but it must include the legitimate origins the website uses. The review itself notes a caveat regarding SRI: it lets the browser reject a script whose content has changed, but it does not apply to scripts that change by design, such as most analytics tags. For those cases, the report points to CSP as a protection.
The contrast between a quick fix and compatibility is especially practical for teams that rely on external providers: the recommendation is not to add controls without checking their effect, but to decide which scripts the page needs and which can be hosted on the site itself. The analysis provides no data on how much work each fix took and does not test the proposed policies on each project; its claim about deployment time is the team's estimate.
What a team should check
The most useful takeaway is not to assume that a particular application is vulnerable, but to review the pages where sensitive actions take place, not just the homepage. The published methodology focused on homepages and acknowledges that the application with the wallet connection may be on another domain. In addition, OWASP recommends checking mobile and accessibility variants: they may have different protections from desktop versions.
It is also worth verifying the headers the browser receives on every relevant page. OWASP warns that proxies can remove or modify headers, and that protection applied to only some pages leaves others uncovered. CSP, framing policy, and HSTS should be evaluated in the actual responses, not only in the configuration the team believes it has deployed.
The review offers a limited snapshot from November 2026, based on the DefiLlama protocol list and a single load of the homepages. It cannot determine how many complete applications inherit the same shortcomings. It does leave every DeFi team with a specific question: does the page displaying the connection button and signature request have the same defenses as its homepage?
Sources: DEV Community, OWASP Foundation
