You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One vulnerability submission that we get a lot of and have to deny is a "self-only" XSS e.g. a user pastes a vulnerable snippet into a comment field, the client-side application renders it as submitted optimistically, but then when the server processes the submission it correctly sanitizes it. This is a really common pattern we see a lot throughout our application due a heavy use of both 1) optimistic rendering and 2) server-side HTML sanitization.
The only self XSS categories currently available are "Reflected > Self-only" and "Stored > Self-only", but neither of those are applicable in this case since the XSS is client-side only and does not involve the server or server responses at all. (Reflected refers to the XSS being sent from the server in some way e.g. a self-only reflected XSS vulnerability would be a "Preview Markdown" API endpoint and a stored self-only vulnerability would refer to e.g. data that is saved in the user's profile but only shown to the user).
Suggestions welcome! From our perspective, this is ~about the same severity as the user being socially engineered into pasting something into their browser's developer console or similar—maybe worth a compensating control in the most sensitive apps, but P5/not really in scope for most teams.
The text was updated successfully, but these errors were encountered:
Hi all!
One vulnerability submission that we get a lot of and have to deny is a "self-only" XSS e.g. a user pastes a vulnerable snippet into a comment field, the client-side application renders it as submitted optimistically, but then when the server processes the submission it correctly sanitizes it. This is a really common pattern we see a lot throughout our application due a heavy use of both 1) optimistic rendering and 2) server-side HTML sanitization.
The only self XSS categories currently available are "Reflected > Self-only" and "Stored > Self-only", but neither of those are applicable in this case since the XSS is client-side only and does not involve the server or server responses at all. (Reflected refers to the XSS being sent from the server in some way e.g. a self-only reflected XSS vulnerability would be a "Preview Markdown" API endpoint and a stored self-only vulnerability would refer to e.g. data that is saved in the user's profile but only shown to the user).
Suggestions welcome! From our perspective, this is ~about the same severity as the user being socially engineered into pasting something into their browser's developer console or similar—maybe worth a compensating control in the most sensitive apps, but P5/not really in scope for most teams.
The text was updated successfully, but these errors were encountered: