Dangerous properties in React are those whose behavior is known to be a common source of application vulnerabilities. The properties names clearly indicate they are dangerous and should be avoided unless great care is taken.
target='_blank'
attribute without rel='noopener noreferrer'
JS-0422When creating a JSX element with a tag, it is often desired to have the link open in a new tab using the target='_blank'
attribute. Using this attribute unaccompanied by rel='noreferrer'
, however, is a severe security vulnerability.
Setting webSecurity
property to false
, or allowRunningInsecureContent
to true
in an Electron renderer process like BrowserWindow
or BrowserView
disables crucial security features. By default, the webSecurity
property is always true
and the allowRunningInsecureContent
property is always false
.
Certificate validation is an important aspect of Transport Layer Security (TLS) connections as it helps to ensure the authenticity and integrity of the data being transmitted. Disabling certificate validation can lead to several security risks, including Man-in-the-Middle Attacks. Without certificate validation, it is possible for an attacker to intercept the communication and present a fake certificate to the client.
In Express, paths specified using string literals are case insensitive, whereas those specified using regex are case sensitive. When a case-insensitive regex is used as a middleware route, attackers can bypass the route by altering the casing of the endpoint they choose to hit.
The nodeIntegration
option in Electron is used to control whether or not the renderer process has access to the Node.js APIs. By default, the nodeIntegration
option is set to false
, which means that the renderer process does not have access to the Node.js APIs. Similarly, the nodeIntegrationInWorker
option is also by default set to false
, so that Electron Web Workers do not have access to the Node.js APIs.
Having hardcoded credentials in your source code, like passwords, tokens, and API keys can lead to security vulnerabilities, even if the source repo is private, and/or self-hosted.
Strict Contextual Escaping (SCE) is a security feature in AngularJS that helps protect against cross-site scripting (XSS) attacks. It is designed to prevent the injection of potentially dangerous content into web applications by escaping or sanitizing user-generated content.
In regular expressions, the -
operator can be used to match a range of characters.
For example, /a-z/
will match any character that has a character code between 'a' and 'z'.
Large ranges, like A-z
, are often the result of typos or incorrect refactors.
The range A-z
will match any character that has an ASCII code between 65 and 122, which includes non-alphabetic characters.
Such behaviour is not obvious from the regex, and might open your application up to vulnerabilities where incoming data isn't properly validated.
Using tainted data in an SQL query – such as query parameters or form input supplied by a user – can leave your application vulnerable to SQL injection attacks.
innerHTML
property JS-S1012The innerHTML
property is capable of directly changing the DOM structure, thereby opening up possibilities for XSS attacks.
If you only want to change the text inside an HTML element, consider using the innerText or textContent property instead.
Avoid assigning values that are fetched from 3rd party sources to HTMLElement#innerHTML
without proper sanitization.
If you must do so, validate and sanitize the data before assignment.
NOTE: If this issue was raised on a code snippet that you're sure was sanitized, consider adding a skipcq comment explaining the reason for the snippet's safety. Alternatively, you could disable this issue for your project in settings.
Using unsanitized external inputs with templating engines can lead to Local File Inclusion (LFI) or Remote Code Execution (RCE) attacks. A specific scenario where such a vulnerability could occur is with the use of ExpressJS in conjunction with Handlebars templating engine.
It is not recommended to use TLS protocol versions less than 1.2. Using outdated TLS protocol versions lead to the use of outdated, vulnerable cipher suites.
Tainted data should never be used in a cookie sent via an HTTP response object. This exposes the application to session fixation attacks.
The errorhandler
middleware should only be enabled in development mode. Enabling this in production can reveal sensitive information about your application to a client. This includes file paths, error messages, directory structure, and debug instructions.
The Referrer-policy
HTTP header controls the amount of referrer information included in requests.
Incorrectly configuring this header can lead to exposure of private data on the referrer's side.
An error thrown by code running in the server should never be exposed to a client. Error
objects contain information like the state of the call stack, bugs in the server code, dependencies used by the server application, etc. An attacker can intentionally send requests that yield an error and get an idea about the server's code layout and possible vulnerabilities.
Cross-Origin Resource Sharing(CORS) is a mechanism that enables web browsers to perform cross-domain requests using the XMLHttpRequest API in a controlled manner. It defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. Using *
, null
or google.com
is not a reliable way to ensure security of the application or software.
The X-Forwarded-For
(XFF) header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or a load balancer.
When traffic is intercepted between clients and servers, server access logs contain the IP address of the proxy or load balancer only. The X-Forwarded-For request header is used to see the original IP address of the client.
If a server makes proxied connections, it is not a good idea to forward user IP addresses using HTTP headers such as X-Forwarded-For
or Forwarded
Context isolation is an Electron feature that allows developers to run code in preload scripts and in Electron APIs in a dedicated JavaScript context. This is important for security purposes as it helps prevent the website from accessing Electron internals or the powerful APIs your preload script has access to.