Stored XSS: Mapping Where User Content Actually Renders

Day six. Today is the highest-paying day of week one.

Reflected XSS needs a victim to click your link. Stored XSS does not. You put the payload in once, and it fires for whoever loads the page — no link, no lure, no social engineering step for a triager to discount. That difference is worth an entire severity band on most programs, and on some it is the difference between a few hundred dollars and a few thousand.

But here is the part people get wrong. They treat stored XSS as reflected XSS with a save button. Inject into the comment box, reload the comment, see if it fires, move on.

That misses the actual skill, which is this: the field where you inject and the page where it renders are two different things, and the second one decides what your bug is worth.

A display name is one input. It renders in the profile header, the comment byline, the team member list, the mention autocomplete, the notification email, the audit log, the admin user table, and the CSV export. Eight render surfaces, eight different templates, eight different escaping decisions made by eight different developers on eight different days. Seven of them might be correctly escaped. The eighth is your bug — and if the eighth is the admin user table, it is a critical.

Today is about building that map systematically.

Step one: inventory every writable field

Before you inject anything, list everything you can write to. Be exhaustive, because the boring fields are the under-tested ones.

Obvious, heavily tested (expect duplicates):

• Comments, posts, messages, reviews
• Display name, username, bio

Less obvious, much better odds:

• Organisation, team, workspace, or project name
• Address fields, especially line two and the state or region field
• Phone number and job title
• Uploaded filenames — the name, not the content
• Saved search names, filter names, view names, label and tag names
• API key or token descriptions
• Webhook URLs and their labels
• Invite messages and referral codes
• Calendar event titles and locations
• Custom field names in anything that supports custom fields
• Anything imported in bulk from CSV or JSON, because import paths frequently skip the validation the UI applies

That last one deserves emphasis. If an application has a manual form and a bulk import for the same data, test both. The form is validated. The importer often is not, because it was written later, by a different team, for trusted internal use, and then exposed to customers.

Step two: tag every field with its own marker

This is the technique that makes the whole method work, and it is a direct extension of day two.

Do not inject the same canary everywhere. Give every field its own traceable marker:

nitnbio01    profile bio
nitnorg02    organisation name
nitnfil03    uploaded filename
nitntkt04    support ticket subject
nitninv05    invite message

nitnbio01    profile bio
nitnorg02    organisation name
nitnfil03    uploaded filename
nitntkt04    support ticket subject
nitninv05    invite message

Why this matters so much for stored XSS: when a marker turns up on a page three clicks away in a part of the app you were not testing, you need to know instantly which field produced it. Without per-field markers you are left re-injecting one at a time to find the source, and if the render surface is one you only reach occasionally, you may not get another chance quickly.

Keep a simple table as you go. Field, marker, where you injected it, date. It takes two minutes and it is the difference between "something fired somewhere" and a reproducible report.

Step three: walk every render surface

Now the actual work. For each marker, find every place it appears. The surfaces people forget:

List views versus detail views. The detail page often escapes properly because it was built first and reviewed. The list, table, or card view was built later, sometimes with a different templating approach, sometimes with string concatenation for performance.

Search results. Frequently a different rendering path, and often one that highlights matched terms by injecting markup around them — which means it is doing string manipulation on your content.

Autocomplete and mention dropdowns. Almost always client-side rendering, often with inner HTML, and almost never reviewed.

Notification and email templates. Your display name in an email is rendered by a completely separate system. Email XSS mostly does not execute in a mail client, but the same template usually backs the in-app notification and the web view of the email, and those do execute.

Exports. CSV, PDF, and XLSX generation. PDF generators are frequently headless browsers, which means HTML injection there can be far more than XSS.

Print and preview modes. Separate stylesheets, separate templates, less review.

Mobile web versus desktop web. Sometimes genuinely different frontends.

Embeds and public share pages. The share view is often a stripped-down renderer built quickly.

Anything with the word "admin", "support", "audit", "moderation", or "review" in it. You cannot see these, which is what week four is about, but you should note every field that plausibly feeds one.

Be systematic. Take one marker, and click through the entire application looking for it. Use the browser's find-in-page. Then view source and search the raw HTML, because a marker can be present in the DOM without being visible on screen — in a title attribute, a data attribute, a hidden input, or a JSON blob.

Step four: the two-account rule

This is non-negotiable for stored XSS and it is where a lot of reports fall apart in triage.

Always test with two accounts you control. Account A injects. Account B views.

If only account A can see the payload, you have self-XSS, which most programs treat as informational until you chain it (day 27). If account B sees it fire, you have real stored XSS and your report writes itself.

Set them up properly: different email addresses, different browsers or containers, no shared session. Then for every marker that rendered, check whether account B reaches that same surface. Some will be private to A. Some will be shared. The shared ones are your bugs.

If the application has roles — owner, admin, member, viewer, guest — test across the role boundary too. A member injecting something that renders in the owner's dashboard is a privilege-escalation-flavoured stored XSS and it should be reported as such.

Step five: rank by who views it

Severity here is almost entirely about the audience:

• Only you → self-XSS, informational until chained
• Users you invited → low to medium, depends on how easy invites are
• Any user of the app → high
• Users in another organisation or tenant → high to critical, and also a tenant isolation finding
• Staff, support, or admin → critical

That last tier is the reason days 24 and 25 exist. If you have mapped a field that plausibly reaches a support console, that is exactly where a blind payload goes.

Practical notes that save you time

Length limits. Many stored fields truncate. If your payload gets cut, use a short one that loads a longer stage from elsewhere, or find a field with a generous limit and use it as the delivery point.

Normalisation. Some fields strip, lowercase, or slugify. Send your character probe from day seven into every field before you conclude anything.

Delayed rendering. Caches, CDNs, and background jobs mean your content may not appear for minutes. Do not conclude "not vulnerable" after one reload.

Moderation queues. Content may be held for review, which means your payload lands in a moderation interface — which is itself an interesting render surface.

Editing versus creating. The create path and the edit path are sometimes different code with different validation. Test both.

Undo the damage. Once you have your evidence, remove the payload. A stored payload left live on a shared page is an incident you caused.

Impact ladder

• Informational — marker renders, fully escaped everywhere. Log the render map anyway. It is reusable on their next release.
• Low — self-only stored XSS. Real, but needs a chain. Day 27.
• Medium — stored XSS visible to users you can invite. The bar is how easy it is to get a victim to the page.
• High — stored XSS on a surface any authenticated user reaches. No interaction, no link, fires on load.
• Critical — stored XSS crossing a tenant or role boundary, or firing in a staff-facing surface. This is both an XSS and an isolation finding, and it should be reported with both framings.

Stored XSS is the class where careless testing does real damage, because your payload persists and other people load it.

Use two accounts you own. Never inject into a field that renders for real customers to "check if it works" — confirm the escaping behaviour with an inert marker first, and only escalate to an executing payload on a surface you have established is limited to your own accounts.

Keep the payload minimal and non-destructive. Proving execution in your own second session is the whole report.

Remove every stored payload once you have your screenshots, and say in the report which fields you wrote to and that you cleaned up. If you cannot remove one, tell them immediately and tell them where it is.

If a payload lands somewhere you did not expect and cannot reach — a support queue, a moderation view — report it promptly rather than continuing to experiment. Someone else has to deal with what you left there.

Conclusion — steal this checklist

• The field you inject and the page that renders are different things. The render surface decides severity.
• Inventory every writable field, including the boring ones: org names, filenames, labels, saved views, key descriptions, invite messages.
• Test bulk import paths as well as forms. Importers routinely skip the validation the UI applies.
• Give every field its own traceable marker so a later hit names its own source.
• Walk every render surface: list versus detail, search, autocomplete, email, export, print, share, mobile.
• View source as well as the page. A marker can sit in a title attribute or JSON blob without being visible.
• PDF export is often a headless browser. HTML injection there can exceed XSS.
• Two accounts, always. A injects, B views. That is what separates stored XSS from self-XSS in triage.
• Test across role boundaries too. Member content rendering in an owner's dashboard is privilege escalation.
• Rank by audience: only you, invited users, all users, other tenants, staff. Staff is critical.
• Watch for truncation, normalisation, caches, and moderation queues before concluding anything.
• Clean up every payload you store, and say so in the report.

Tomorrow: the character probe — building a complete filter fingerprint in about ten requests, so you stop guessing which bypass to try.

If you Love reading my blogs. Check my Youtube Channel too.