4 ms·
>No, the application should be resistant to XSS instead Or we can admit that vulnerabilities are a likely possibility, despite all of our efforts. Therefore th
by alex_duf 3y ago
>No, the application should be resistant to XSS instead
Or we can admit that vulnerabilities are a likely possibility, despite all of our efforts. Therefore the most secure approach is to understand that limiting the impact of one vulnerability is a reasonable way of dealing with it.
Otherwise you're suggesting running application code as root on the machine isn't a problem, since your application has no vulnerability.
- aidos 3y agoI don’t understand the downvotes here. The application should be as resistant to xss as possible but things do sneak through and we should try to limit the damage in other layers. An example is that you could think you have no xss issues because you use react to do your rendering. Meanwhile you have a window.location = something_from_url which is just as capable of running js code if you’re not careful. Having the auth (whatever it is) in a http only cookie is one protection. Having it time limited is another. For some applications locking it to an ip address might make sense. It’s not an either / or thing.
- marius_k 3y agoUsing xss one might target login form and steal username/password instead of a token. So I do not see argument here against jwt. Sure the xss will have to be more sofisticated(?)
- aidos 3y agoI’m not arguing for / against any specific technology. I’m saying that relying on a lack of security flaws in one layer isn’t a great idea.