Author: Kateryna Ivanenko, Invicti Brand Manager
JavaScript is a powerful and widely used programming language for building web applications. However, common security mistakes can be made in it, and they may increase the risk of successful cyberattacks.
Lack of Content Security Policy (CSP)
CSP is an HTTP header that allows the site owner to specify from which sources content (scripts, styles, images, etc.) is allowed to be loaded.
It protects against XSS (cross-site scripting) attacks and some injections, so its presence is significant.
To avoid this mistake, teams should always implement strict CSP headers, such as default-src ‘self’; script-src ‘self’; object-src ‘none’.
Insecure data storage in LocalStorage/SessionStorage
Storing sensitive data (e.g. tokens) in unencrypted form in LocalStorage/SessionStorage is accessible via JavaScript.
For example, this can lead to token theft, XSS, and unauthorized account access.
It is better to store sensitive data in HTTP-only cookies with the Secure and SameSite attributes. They are inaccessible to JavaScript, and therefore are not vulnerable to, for example, XSS.
Lack of user input validation
It is important to validate user input on both the client and server sides, which some forget, because validation only on the client side can be easily bypassed.
This can lead to critical vulnerabilities such as SQL injections, system command injections, XSS attacks, as well as unauthorized data creation or modification.
It is imperative to implement input validation and treat any data received from the user as potentially dangerous.
Storing CSRF tokens in cookies
If an application uses cookie-based authentication for user auth, an attacker can access the session cookie and act on the user`s behalf. Such CSRF attacks are among the most common JavaScript vulnerabilities.
This problem can be avoided by passing an additional token with each HTTP request. Since CSRF tokens are not stored in cookies, an attacker cannot intercept them. These tokens can be added to forms, AJAX calls, HTTP headers, hidden fields, and other elements.
Below is an example of a CSRF token from the OWASP project that can be added to a form as a hidden field:
**
<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZMGYwMGEwOA==">
[...]
</form>
**Insecure cookie transmission
To further enhance cookie security, teams should ensure that cookies are only transmitted over a secure protocol, such as HTTPS, which encrypts data between the client and server. The use of a secure protocol can be enforced by adding the ;secure flag to the Document.cookie property, which provides access to the document’s cookie.
It can be used in conjunction with the ;samesite flag, which allows teams to control the transmission of cookies across cross-site requests. For example, using the lax value makes it possible for cookies to be passed on all requests within a site and for top-level navigation using the GET method. This allows for user tracking, but at the same time prevents a significant portion of CSRF attacks.
Using outdated or vulnerable libraries
Using third-party libraries without proper version control and updates creates security risks, as they can be vulnerable to numerous cyberattacks.
Possible consequences include Remote Code Execution, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and other attacks.
It is recommended to use Software Composition Analysis (SCA) tools such as Mend.io to identify vulnerable libraries.
Additional recommendation
It is important to use DAST web scanners such as Invicti to check the security of websites. The solution effectively finds all vulnerabilities and confirms the existence of key ones.
To make sure of this, you can test Invicti for free, for this please contact us in a way convenient for you.
