By user isolated, I mean that users interact with server and have some personalized data and they can read, update, delete their data but they will never see another user made data (like facebook, stackexcahnge, email). An example for a user isolated app would be a note taking app, todo list app etc.

In this case should I worry about the XSS possibility? Should I check the inputs and sanitize them for every request?

  • It all depends on how that isolation occurs...
    – schroeder
    Commented Jul 20, 2020 at 20:58

1 Answer 1


In this case should I worry about the XSS possibility? Should I check the inputs and sanitize them for every request?

Yes, you should worry about this foundational piece of security. Even if you can't currently envision an attack vector today, as your software evolves, you are leaving landmines in your wake that you will quickly forget about. It will become impossible to confidently build on this foundation.

We are constantly shocked by new and novel attacks, and they almost always involve chaining together multiple seemingly minor exploits in a novel and disastrous way. Don't knowingly give attacker an XSS exploit for free, you have no idea how that will combine in unexpected ways with other exploits you don't know about.

While the following is somewhat subjective, I'm an application developer of some 20 years and have been deeply interested in security for most of that time. I would say that the almost inevitable outcome is of this type of thinking is:

We ignored security when writing "feature X" because it was not exploitable when we built it, but changing product requirements exposed vulnerabilities in a way we didn't foresee... And now we're in trouble.

This mindset leads to some of the worst exploits; when you make a conscious decision to ignore security, and then something changes and suddenly it matters, the types of vulnerabilities you wind up exposing are catastrophic and so foundational that it can be easier to start over.

It's also much harder to find all vulnerabilities in a large sprawling application that was started in such an incorrect way, when you eventually do realize it's important. Especially if you have multiple developers, each one may make some haphazard attempt to secure the next thing they add, often in conflicting or overlapping ways that ultimately pile up as technical debt. Don't leave it to chance, and don't require each subsequent developer to "solve" security, set the tone of the project from day one.

I will also say that, if you do this professionally, you should have some pride in your craft. Learn to build software correctly always, not just went you think it's important. Building software correctly includes building software that is secure by default, not just when you remember to add security. Experience you gain building it correctly now makes you better prepared to build it correctly when you do decide it matters.

Finally, it should be no extra effort to just build it correctly from the outset. Use a sensible framework as intended and most types of vulnerabilities are already handled for you. You shouldn't have to write your own code for preventing XSS or SQL injection, I haven't had to do this in more than a decade. Every major framework has solved these problems better than you or I can. I've built the sandboxed note-taking app you're describing. I'm the only user, but I can tell you it has no vulnerabilities in it (famous last words) because I wrote it in Rails and Vue, mature technologies that handle most types of mitigation. I used these technologies not because I wanted security but because I wanted a rich feature set and mature ecosystem. Security came free.

  • Solid advice. Build on a rock, not on sand. Build ignoring security, and later you have "share notes" functionality implemented...
    – ThoriumBR
    Commented Jul 21, 2020 at 2:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .