Skip to content

Instantly share code, notes, and snippets.

What would you like to do?


Review of postxss in repect to Strawman proposal for a "Safe Node" in the DOM. I suggest a less complicated syntax, using a/series of disable-[ELEMENT] (e.g. disable-form and/or disable-script) atrributes of current/custom elements.


<div disable-form disable-script disable-link id="user-gen-content">
  <form action="">
  <script src=""></script>
  <link rel="alternate" type="application/atom+xml" href="
{}*{color:red;}//styles/prosilver/theme/feed.php" /> <!-- -->


on event tags

On event attributes <button onclick="alert('hello')"> would be blocked via disable-script.


Should disable-styles include <style> and <link rel="stylesheet" or should disable-links be required?

Blocking of network

There would be no pervision for explicitly blocking netowrk acsses or limiting it to a defined set of URLs. To block network then disable-script disable-style disable--img disable-link would be required (and potentially more).


Should disable-* be allowed and enable-[ELEMENT] be included?

Post XSS

2.1 Dangling markup injection

This feels like a code bug that any additinal features will paper over rather than root cause fix

2.2 <textarea>-based consumption

<div disable-form>
<form action=''><textarea>           ← Injected line
<input type="hidden" name="xsrf_token" value="12345">

##2.3. Rerouting of existing forms

<div disable-form>
<form action=''>                     ← Injected line
<form action='update_profile.php'>                          ← Legitimate, pre-existing form
<input type="text" name="real_name" value="John Q. Public">

2.4. Use of to hijack relative URLs

<div disable-base>[input]</div>

2.5. Form injection to intercept browser-managed passwords

I think this should be managed by the browsers and not by publishers and new syntax/features.

2.6. Addendum: The limits of exfiltration defenses

<div disable-form>[input]</div>

3.1. Interference with existing scripts

<div disable-script>[input]</div>

3.1.1. HTML namespace attacks

This would not explicitly protect this however. If the syntax was extended to be disable-attrib-[ATTRIBUTE] eg. disable-attrib-checked or disable-attrib-id it could be prevented. However this feels more like whack-a-mole.

3.1.3. Script load order issues (CSP-specific)

<div disable-script>[input]</div>

3.1.4. Abuse of JSONP (CSP-specific)

<div disable-script>[input]</div>

3.2. Form parameter injection

<div disable-form>[input]</div>

3.3. UI-level attacks

This would be a bit whack-a-mole as this design would not change CSS rules appiled to the element as so any content would look like the publisher. I would seggest the use of <div class="user-gen-content" disable-style disable-link>[input]</div> and apply a differing style to the block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment