Scam Alert: False Vulnerability Reports from "Security Researchers" Using X-Frame-Bypass Library

[pauliusjacionis]

Hello everyone,

I recently received an email from a "security researcher" who used the X-Frame-Bypass library to report an "X-Frame-Options bypass bug". They were expecting a bug bounty payment.

I want to draw attention to this: the library DOES NOT actually bypass X-Frame-Options; it only creates the illusion of a bypass. Because traffic is proxied through a different domain name, session data and cookies are lost. This "bypass" is entirely harmless.

Be cautious of bug bounty scams and fraudulent security researchers.

[0xYudhishthra]

Hey @pauliusjacionis, thanks for raising this! I saw a bug bounty report similar to what you mentioned using this tool to bypass X-Frame-Options, and the reporter suggested using the "Content-Security-Policy: frame-ancestors 'self';" header. Any thoughts on alternative measures that can be implemented besides depending solely on the CSP header?

[Kcin41]

We have had a similar attempt at my company. All that was shown as evidence was a sign in page on their localhost as well as the HTML from that page they were hosting. Just to reaffirm others, @pauliusjacionis is correct as far as I can tell with a quick dive into it.

[pauliusjacionis]

Hey @pauliusjacionis, thanks for raising this! I saw a bug bounty report similar to what you mentioned using this tool to bypass X-Frame-Options, and the reporter suggested using the "Content-Security-Policy: frame-ancestors 'self';" header. Any thoughts on alternative measures that can be implemented besides depending solely on the CSP header?

Proxy servers can strip headers, meta tags, and modify HTML. The suggested solution would not fix the "vulnerability".

This is a scam. There is no vulnerability, and there is no fix.

The scammers claim they can clickjack your website, but that is not what is happening. They are clickjacking a different domain name. Sure, it appears to be your website, but it is not. It's just a live copy of your website. They could simply upload a copy of your website's HTML on their server and achieve the same result—no proxy needed.

[HansSchouten]

Thanks for posting the clarification. Bug bounty scammers are still active. Please consider pinning this issue or add a small reference in the readme

[jarthod]

+1, just received one too and was highly sceptical as usual (I couldn't see how this could be exploited for real) but I didn't know about this so I investigated a bit to learn about the CSP attribute they mention. Thanks for confirming here as it saved me some reading and testing 🙇‍♂️ . I guess this is a good "vulnerability" for the scammers because it is:

• Rather new and unknown to most web dev
• Easy to show a simple screenshot as "proof"
• Easy to automate to find websites which have one header but not the CSP

As I checked this project right after receiving the report, I agree with @HansSchouten it would be nice to add some line to the readme just to warn the future victims and save them some time. I understand this shouldn't be the responsibility of the library writer to deal with scammers, but unfortunately I don't see a better place to help the targets.

[ShaiMagal]

We are facing the same scammers, thank you for unambiguous information! :)

[laliconfigcat]

We are facing the same scammers, thank you for the information. This issue should be definetely pinned somehow or the information should be added to the readme to help others. We were sceptical too (as usual) and this issue saved a lot of testing/reading. Thanks!

[sappawatpop123]

For other readers: Please carefully read each comment before judging whether this is a scam or not. Header stripping is also mentioned in the OWASP Clickjacking Defense Cheat Sheet. According to the source code, it does indeed strip headers to bypass X-Frame-Options, allowing the website to be visible in external iframes.

However, I’ve tested this script on various websites, and some are able to mitigate the issue, as seen through console errors related to Cross-Origin Resource Sharing (CORS) and Content-Security-Policy (CSP). If this were purely a scam, it would likely impact all websites consistently and immediately.

Although the script may appear suspicious, in practice it utilizes a header-stripping technique via a proxy, allowing a target site to be rendered within another site's iframe and enabling phishing elements—such as fake login forms—to be layered on top. This still constitutes a clickjacking risk.

I agree that this should not be included in a bug bounty program since it is an indirect vulnerability, such as password brute force, weak password policies, lack of rate limiting, missing HTTP security headers, and others, which are commonly not accepted by many bug bounty programs. However, in the case of a penetration testing engagement, this can still be considered a finding to help enhance web security.

Therefore, we should have a broader discussion about what defines a “clickjacking vulnerability” and what constitutes acceptable prevention measures.

Note: In my opinion, the most robust way to prevent clickjacking is to use a combination of X-Frame-Options, Content-Security-Policy, and a frame-busting script specifically designed to defend against this type of attack (HTTP header stripping by a proxy server).

Please visit https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html for reference.

[pauliusjacionis]

@sappawatpop123 I understand your concern, and your advice on using headers is very valuable. That said, I believe this is a scam, or at the very least, a deceptive report. Let me explain.

Please carefully read each comment before judging whether this is a scam or not.

TL;DR In one sentence: It’s a deceptive tactic where they are faking clickjacking and demanding a payment for it.

Longer version:

They claim they can demonstrate a clickjacking attack on your website, but they demonstrate clickjacking on a different domain name (one they control).

It’s convincing because it appears that your website was loaded in an iframe, but it’s just a deception. Your website was not loaded. What is being loaded in the iframe is their domain name that hosts a copy of your (very recent) HTML. However, their server does not have access to your cookies, session data, or your backend. And yet, they claim they can clickjack your website (they can't).

If they could actually perform clickjacking on your domain/website, they wouldn't need to fake it with this library.

Even with all standard mitigations in place, this library can still display a static copy of your site -- but it doesn’t reflect a real vulnerability.

Header stripping is also mentioned in the OWASP Clickjacking Defense Cheat Sheet.

I could be wrong here, but I believe OWASP is referring to a different kind of proxy: reverse proxies or CDN edge servers (e.g. Cloudflare) that sit in front of your domain and serve your actual content. In those cases, a misconfigured proxy could unintentionally strip important security headers like X-Frame-Options, which would be a real risk.

But this library doesn't use your domain name. It just downloads your public HTML and serves it from a different domain entirely.

According to the source code, it does indeed strip headers to bypass X-Frame-Options, allowing the website to be visible in external iframes.

That's technically correct, but in principle wrong. Your website does not load in an external iframe. A copy of your (publicly facing) HTML is being loaded in an iframe. You could achieve the same result with any website by simply copying the website's HTML code in developer tools and uploading it to your server. That's not a security vulnerability, that's just a copyright infringement.

However, I’ve tested this script on various websites, and some are able to mitigate the issue, as seen through console errors related to Cross-Origin Resource Sharing (CORS) and Content-Security-Policy (CSP). If this were purely a scam, it would likely impact all websites consistently and immediately.

Yes, if HTML has references to resources that are delivered with security headers (let's say JavaScript initiates an AJAX call), you will see these errors. And yet, the person behind this report will still email you about this "vulnerability".

Although the script may appear suspicious, in practice it utilizes a header-stripping technique via a proxy, allowing a target site to be rendered within another site's iframe and enabling phishing elements—such as fake login forms—to be layered on top. This still constitutes a clickjacking risk.

The site that is being loaded in an iframe is controlled by the attacker. So the site that's at risk of clickjacking is not yours.

To serve phishing elements, such as fake login forms, you don't need this library. Just create a website similar to your victim's and serve it from your own server/domain name. As mentioned before, that's what this library does - serves a copy of your public-facing HTML.

I agree that this should not be included in a bug bounty program since it is an indirect vulnerability

I'd argue it doesn’t belong in a bug bounty program because it relies on misrepresentation, not an actual vulnerability in your system.

However, in the case of a penetration testing engagement, this can still be considered a finding to help enhance web security.

Any publicly accessible website could be misrepresented this way, but that doesn’t make it vulnerable.

Therefore, we should have a broader discussion about what defines a “clickjacking vulnerability” and what constitutes acceptable prevention measures.

I'd draw the line on this - it can only be called "clickjacking vulnerability" if it can be performed on your website.

Can they clickjack your website? No? Then there's no clickjacking vulnerability. Can they clickjack a website they control (on their own server)? Yes? Then it’s still not clickjacking ON YOU, but technically you can say they clickjacked themselves. In this case, your domain is unaffected, since the demonstration doesn't involve your actual server or session context.

A clickjacking vulnerability should only concern you if your domain/website is actually vulnerable. However, in this case, the attacker’s domain name (which they control and use to output the HTML) is being used to demonstrate “vulnerability”, not yours. Once they can demonstrate that they can perform clickjacking on your domain, then it’s a real concern. But they can’t. If they could, they wouldn’t need this library to fake it.

Note: In my opinion, the most robust way to prevent clickjacking is to use a combination of X-Frame-Options, Content-Security-Policy, and a frame-busting script specifically designed to defend against this type of attack (HTTP header stripping by a proxy server).

I had both headers present and still received the email claiming a vulnerability.

A frame-busting script in this case wouldn't work because the attacker can still remove it from the source code. They control the server delivering that HTML.

Thank you for your thoughtful response @sappawatpop123. I'll admit that it took me some time to figure out what's going on when I received this "vulnerability report". This tactic is quite clever.

And yes, people, have your security headers set. It will not prevent scammers hitting your inbox, but it will prevent real vulnerabilities.

[sappawatpop123]

@pauliusjacionis Yeah, I think your point of view is also valid. It could be something like copying the entire code from the inspector and rendering it to the victim, or a forward proxy server stripping headers—then a malicious actor could use that proxy to perform clickjacking.

However, I still notice that some sites, like ChatGPT, are able to mitigate this issue. This shows that some websites are aware of it and have taken steps to remediate it.

Anyway, I personally adhere to OWASP guidelines when testing for clickjacking, since they’re based on input from more than just a single person's opinion:

"Web proxies are known for adding and stripping headers. In cases where a web proxy strips the X-FRAME-OPTIONS header, the site loses its framing protection."

I might be wrong, you might be wrong—or even OWASP could be wrong. I think we should involve more people, especially from the OWASP community, to clarify this issue so we can establish better standards for both penetration testing and bug bounty programs.

That said, I still agree this kind of finding should not be eligible for a bug bounty, and I condemn anyone who insists on a reward for it. That kind of behavior undermines the trust and integrity of the cybersecurity community.

Thank you @pauliusjacionis for your discussion about the bad behavior of bug bounty hunters and your thoughtful response.

[Kcin41]

I am still with @pauliusjacionis on this one. Also, @sappawatpop123, what script were you running against other sites? And always be sure you have permission to do so.

Anyway, I personally adhere to OWASP guidelines when testing for clickjacking, since they’re based on input from more than just a single person's opinion:

This really isn't an "opinion", @pauliusjacionis did some testing, I did some testing, we did research. This is really not a true vulnerability. I do penetration testing as part of my daily job and have some training in it. I am not the best in the world for sure, but I do know enough to figure out a "vulnerability" report is fake. These people making these reports are relying on getting a company that doesn't have the in-house staff with the ability to disprove these things. And also, OWASP itself is really just the "opinion" of other security professionals.

"Web proxies are known for adding and stripping headers. In cases where a web proxy strips the X-FRAME-OPTIONS header, the site loses its framing protection."

Yeah proxies can strip headers, that is a feature of them for security reasons. But it's really not applicable here unless your site is being passed through a proxy before being served to the end user. An attacker running a burp suite proxy, or recreating the site locally, or whatever local action they take, as is the case in these bug reports, is not the same thing. I can make any site vulnerable on my localhost if I strip out enough things. Which is what the "researchers" are claiming here.

I might be wrong, you might be wrong—or even OWASP could be wrong. I think we should involve more people, especially from the OWASP community, to clarify this issue so we can establish better standards for both penetration testing and bug bounty programs.

Again, @pauliusjacionis is right on this one, and saying that one of the main web security authority organizations could be wrong on something as simple as clickjacking is an interesting take. As for better establishment of penetration testing and bug bounty programs, that is already quite well defined. It just depends if people adhere to them. If you have done some OffSec courses, other other penetration testing training companies, they outline penetration testing practices VERY well. As for bug bounties, each company is free to determine their program as they see fit. But there are general standards out there that companies like HackerOne and others have laid a solid template for.

[sappawatpop123]

@Kcin41 I couldn’t agree more. You made a very clear and valid point. It really depends on whether people follow standards—whether that's OWASP, OffSec, HackerOne, or their own internal guidelines. Thank you very much for your thoughtful response, and I apologize if any of my points were invalid.