Security Plugins (11+)
Vulnerability detection with CWE/OWASP mapping. Every rule is actionable and AI-parseable.Quality Plugins (7+)
Code architecture, conventions, and maintainability. Rules that prevent tech debt.<script>steal(cookies)</script> App->>App: Store input without sanitization Victim->>App: View page with malicious content App->>Victim: element.innerHTML = userInput Victim->>Victim: Browser executes injected script Victim->>AttackerServer: Session cookie stolen! Note over Attacker,AttackerServer: Attacker now has victim's session ``` ## Examples [#examples] ### ❌ Incorrect [#-incorrect] ```javascript // Direct assignment of user input - CRITICAL XSS element.innerHTML = userInput; // Template literal with user data - VULNERABLE element.innerHTML = `
${userData.name}
`;
// Function result without sanitization - VULNERABLE
element.innerHTML = getUserContent();
element.outerHTML = fetchedData;
// React dangerouslySetInnerHTML (different rule, same concept)
;
```
### ✅ Correct [#-correct]
```javascript
// Use textContent for text - SAFE
element.textContent = userInput;
// Sanitize with DOMPurify - SAFE
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userInput);
// Literal strings are safe
element.innerHTML = 'Static content
'; // Create elements programmatically - SAFE const div = document.createElement('div'); div.textContent = userInput; container.appendChild(div); ``` ## Options [#options] | Option | Type | Default | Description | | --------------------- | ---------- | ----------------------------------------------------------------- | ----------------------------------------------- | | `allowInTests` | `boolean` | `false` | Skip this rule in `*.test.*` / `*.spec.*` files | | `trustedSanitizers` | `string[]` | `["DOMPurify.sanitize","sanitize","sanitizeHtml","xss","purify"]` | Extra function names to treat as sanitizers | | `allowLiteralStrings` | `boolean` | `true` | Allow innerHTML with literal strings | ```json { "rules": { "browser-security/no-innerhtml": [ "error", { "trustedSanitizers": ["DOMPurify.sanitize", "myCustomSanitizer"], "allowLiteralStrings": true } ] } } ``` ## Best Practices [#best-practices] ### 1. Use DOMPurify [#1-use-dompurify] ```javascript import DOMPurify from 'dompurify'; function renderUserContent(html) { return DOMPurify.sanitize(html, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a'], ALLOWED_ATTR: ['href'], }); } element.innerHTML = renderUserContent(userInput); ``` ### 2. Prefer textContent [#2-prefer-textcontent] ```javascript // For plain text, always use textContent element.textContent = userData.name; // Safe - no HTML parsing ``` ### 3. Use DOM APIs [#3-use-dom-apis] ```javascript // Build DOM programmatically function createComment(user, text) { const div = document.createElement('div'); div.className = 'comment'; const author = document.createElement('span'); author.textContent = user.name; // Safe const content = document.createElement('p'); content.textContent = text; // Safe div.appendChild(author); div.appendChild(content); return div; } ``` ## Related Rules [#related-rules] * [`no-eval`](./no-eval.md) - Detects dangerous eval usage * [`no-sensitive-localstorage`](./no-sensitive-localstorage.md) - Detects sensitive data in localStorageyour sensitive data! M->>M: Exfiltrate user data ``` When you use `postMessage(data, "*")`: 1. **Any window** that has a reference to your window can receive the message 2. Attackers can embed your site in an iframe and listen for messages 3. Sensitive data (tokens, user info) can be exfiltrated ## Examples [#examples] ### ❌ Incorrect [#-incorrect] ```javascript // Wildcard allows any window to receive the message window.postMessage(userData, '*'); // Also dangerous with iframes iframe.contentWindow.postMessage(authToken, '*'); // Parent window communication parent.postMessage({ type: 'auth', token: jwt }, '*'); // Window opener window.opener.postMessage(sensitiveData, '*'); // Options object with wildcard window.postMessage(data, { targetOrigin: '*' }); ``` ### ✅ Correct [#-correct] ```javascript // Specify the exact origin window.postMessage(userData, 'https://trusted-domain.com'); // iframe with known origin iframe.contentWindow.postMessage(authToken, 'https://embed.myapp.com'); // Parent window with specific origin parent.postMessage({ type: 'auth', token: jwt }, 'https://parent.myapp.com'); // Use "/" for same-origin communication window.postMessage(data, '/'); // Options object with specific origin window.postMessage(data, { targetOrigin: 'https://trusted-domain.com' }); ``` ## Options [#options] | Option | Type | Default | Description | | -------------- | --------- | ------- | ----------------------------------------------- | | `allowInTests` | `boolean` | `true` | Skip this rule in `*.test.*` / `*.spec.*` files | ```json { "browser-security/no-postmessage-wildcard-origin": [ "error", { "allowInTests": true } ] } ``` | Option | Type | Default | Description | | -------------- | --------- | ------- | ---------------------------------------------------- | | `allowInTests` | `boolean` | `true` | Skip checking in test files (\_.test.ts, \_.spec.ts) | ## When Not To Use It [#when-not-to-use-it] You may disable this rule if: * Your application only sends non-sensitive public data via postMessage * You're building a development tool where security isn't a concern * You have other mechanisms to prevent cross-origin message interception However, it's generally recommended to **always specify the exact target origin**. ## Related [#related] * [CWE-346: Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) * [MDN: postMessage Security Concerns](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#security_concerns) * [`browser-security/require-postmessage-origin-check`](./require-postmessage-origin-check.md) - Validates origin on message receipt
Hello World
'); }); // Rendering a view without global CSP middleware app.get('/home', (req, res) => { res.render('index', { title: 'Home' }); }); ``` ### ✅ Correct [#-correct] ```javascript res.send({ data: 'json' }) ```and modify all traffic! ``` When you use `ws://`: 1. **All data is transmitted in plaintext** - anyone on the network can read it 2. **No authentication of the server** - you might connect to an attacker 3. **Data can be modified** - MITM can inject malicious content ## Examples [#examples] ### ❌ Incorrect [#-incorrect] ```javascript // Unencrypted WebSocket - vulnerable to MITM const ws = new WebSocket('ws://api.example.com/socket'); // With port const ws = new WebSocket('ws://chat.example.com:8080/ws'); // Template literal const ws = new WebSocket(`ws://api.example.com/user/${userId}`); ``` ### ✅ Correct [#-correct] ```javascript // Secure WebSocket const ws = new WebSocket('wss://api.example.com/socket'); // With port const ws = new WebSocket('wss://chat.example.com:8080/ws'); // Template literal with wss const ws = new WebSocket(`wss://api.example.com/user/${userId}`); // Localhost is allowed by default (for development) const ws = new WebSocket('ws://localhost:3000'); const ws = new WebSocket('ws://127.0.0.1:8080'); ``` ## Options [#options] | Option | Type | Default | Description | | ---------------- | --------- | ------- | ------------------------------------------------------ | | `allowInTests` | `boolean` | `true` | Skip this rule in `*.test.*` / `*.spec.*` files | | `allowLocalhost` | `boolean` | `true` | Allow ws\:// for localhost/127.0.0.1 (for development) | ```json { "browser-security/require-websocket-wss": [ "error", { "allowInTests": true, "allowLocalhost": true } ] } ``` | Option | Type | Default | Description | | ---------------- | --------- | ------- | ------------------------------------------------------ | | `allowInTests` | `boolean` | `true` | Skip checking in test files (\_.test.ts, \_.spec.ts) | | `allowLocalhost` | `boolean` | `true` | Allow ws\:// for localhost/127.0.0.1 (for development) | ## Auto-Fix [#auto-fix] This rule provides an **auto-fix** that replaces `ws://` with `wss://`: ```javascript // Before (auto-fix available) const ws = new WebSocket('ws://example.com'); // After auto-fix const ws = new WebSocket('wss://example.com'); ``` ## When Not To Use It [#when-not-to-use-it] You may disable this rule if: * You're running a WebSocket server that explicitly requires unencrypted connections (not recommended for production) * You're in a controlled internal network with no untrusted parties However, **always use `wss://` in production**. The performance overhead of TLS is minimal compared to the security benefits. ## Related [#related] * [CWE-319: Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) * [MDN: WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) * [CVE-2024-37890: WebSocket DoS Vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2024-37890)
Hello ' + req.body.name + '
'); ``` ```js const _ = require('lodash'); _.template(`${userSuppliedLayout}
`);
```
Examples of **correct** code:
```js
const Handlebars = require('handlebars');
// The template is static; the user input is DATA.
const greet = Handlebars.compile('