Reflected XSS in HTML Context with All Standard Tags Blocked Except Custom Ones
Discover how attackers bypass tag filters using custom HTML elements and event handlers to trigger XSS.
Reflected XSS in HTML Context with All Standard Tags Blocked Except Custom Ones
Discover how attackers bypass tag filters using custom HTML elements and event handlers to trigger XSS.
🔓 **Free Link**
Reflected XSS in HTML Context with All Standard Tags Blocked Except Custom Ones
Disclaimer: The techniques described in this document are intended solely for ethical use and educational purposes. Unauthorized use of these methods outside approved environments is strictly prohibited, as it is illegal, unethical, and may lead to severe consequences.
It is crucial to act responsibly, comply with all applicable laws, and adhere to established ethical guidelines. Any activity that exploits security vulnerabilities or compromises the safety, privacy, or integrity of others is strictly forbidden.
Table of Contents
Summary of the Vulnerability
Cross-site scripting (XSS) vulnerabilities can surface in unexpected places — even when a web application blocks all standard HTML tags. In this lab challenge provided by PortSwigger, the page reflects unsanitized input back into an HTML context, but with a twist: it filters out all standard tags (**<script>, `<img>**,<svg>`, etc.) and only allows custom tags.
This lab at PortSwigger Academy presents a web application that reflects user input into the HTML body, then filters all standard HTML tags. Allows non-standard/custom tags (e.g., **<foo>, `<bar>`**), and does not sanitize event handler attributes.
Steps to Reproduce & Proof of Concept (PoC)
① Open the Lab
② Test with a Basic HTML Tag
- Try injecting a simple standard tag in the search input, like
**<body>**.
- You’ll notice that this input is blocked, and no script execution occurs. The application is filtering out all standard tags.
③ Identify Allowed Tags Using Burp Intruder
- In Burp Suite, go to the HTTP history tab.
- Find the GET request triggered by your test input.
- Right-click the request → Send to Intruder.
- Grab a list of event handler tags from the official **PortSwigger XSS Cheat Sheet**.
- Highlight the tag part (
**<$$>**) in the payload and set it as the attack position.
- On the right side, go to Resource Pool → Create new resource pool → Maximum concurrent request = 1.
④ Analyze the Results
Once the attack finishes:
- Look for responses with HTTP 200 and a reflected payload.
- You’ll see that custom tags like
**<audio2>** are accepted by the server.
In this walkthrough, we’ll use **<audio2>** as our working tag.
⑤ Build the Working XSS Payload
Back on the **XSS Cheat Sheet, locate `audio2` in the custom tags** section.
Copy a working payload. For example:
<audio2 autofocus tabindex=1 onfocus=alert(1)></audio2>⑥ Test in the Application
- Paste the payload into the search input field and hit Enter.
- If successful, a popup will appear displaying
**alert(1)**. This means your XSS injection worked.
⑦ Prepare the Exploit
Now, go to the Exploit Server provided by PortSwigger to prepare the delivery.
- First attempt: wrap the target URL in an
**<iframe>**. But upon testing, you’ll notice that the site does not allow iframe embedding (blocked via X-Frame-Options).
- Second attempt: redirect the victim using JavaScript
<script>
window.location="https://0ab900a9035c972e804fe48c0056008d.web-security-academy.net/?search=<audio2 autofocus tabindex=1 onfocus=alert(document.cookie)></audio2>";
</script>
This safely redirects the victim to the vulnerable endpoint with your working payload.
⑧ Final Steps: Deliver and Solve
- In the Exploit Server, paste your working redirect payload.
- Click “Store” and then “Deliver exploit to victim”.
- Wait a few seconds.
If the popup triggers on the victim’s browser, the lab marks as Solved.
Impact
- Once arbitrary JavaScript executes, attackers can access sensitive data such as cookies, session tokens, or local storage — especially if
**HttpOnly** flags are misconfigured. - Web developers often assume that removing dangerous tags like
**<script>or `<img>`** is enough. However, WAFs and sanitizers that only blacklist standard tags miss custom tag abuse — Bypassing WAF.
📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:
- 📖 Medium: bashoverflow.medium.com
- 🐦 Twitter / X: @_havij
- </> Github: havij13
🙏Your support is appreciated.
메타데이터
- post_id
- 72e2f0b34131
- slug
- reflected-xss-in-html-context-with-all-standard-tags-blocked-except-custom-ones-72e2f0b34131
- url
- https://osintteam.blog/reflected-xss-in-html-context-with-all-standard-tags-blocked-except-custom-ones-72e2f0b34131
- canonical_url
- https://osintteam.blog/reflected-xss-in-html-context-with-all-standard-tags-blocked-except-custom-ones-72e2f0b34131
- author_url
- https://medium.com/@bashoverflow
- status
- ok
- fetched_at
- 2026-08-18 07:42:55
