Tag Info

New answers tagged

3

What if they entered their email as "></a><script>alert("XSS")</script><a href=" which (might) be rendered by the application as <a href="mailto:"></a><script>alert("XSS")</script><a href="">"></a><script>alert("XSS")</script><a href="</a>. giving rise to a Stored XSS ...


4

Avoiding attacks on your site You need to validate that the string you received is valid. Remember this principle: you must white-list acceptable strings rather than black-list unacceptable ones. Ensure that the string is a syntactically-correct and escaped URL. Escaping the whole URL avoids it containing " or > which could break your site's syntax. ...


0

Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice. Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers). While zero day vulnerabilities may exist in the various browser rendering engines ...


4

This is client-side security. You are not able to fully secure your data on the client. This means, the user always has the possibility to "change" his role. I put this in quotes because he can't actually change the role, he just sends you his profile with another role. He could do this like you said, inspect the element and remove attributes. But he could ...


4

Don't rely on the client. That is, security on the client-side is not security. Any security checks you do, or assumptions you make, on the client (aka HTML, javascript, etc) are irrelevant, and need to be performed on the server. When the user submits the form, simply disallow any values the user is not authorized to. And while you're at it, don't even ...


17

The "better way" is server-side validation, because you simply cannot control what the client will send. It does not matter what client-side method you use - <input maxlength=, javascript, what-have-you. To quote OWASP: Note that client side validation is a fine idea for performance and usability, but it has no security benefit whatsoever. Server ...


4

Nope. That's pretty much the best you can do on the client. The key is to have strong input validation on the server. Always treat all input as suspicious. Input validation on the client is to improve the user experience. The security happens on the server. PS: You could add JavaScript validation but it adds no real security because an attacker can bypass ...



Top 50 recent answers are included