Four rule families cover the common sinks: react/no-danger for dangerous JSX props, vue/no-v-html for the v-html directive, and the core no-eval, no-implied-eval and no-new-func rules for code built from strings. They find sinks quickly, but a reviewer still has to judge each one.
What each rule does
| Rule | Plugin | What it reports |
|---|---|---|
| react/no-danger | eslint-plugin-react | Dangerous JSX properties, those whose behavior is a common source of vulnerabilities |
| vue/no-v-html | eslint-plugin-vue | Every use of the v-html directive, to reduce the risk of injecting unescaped HTML |
| no-eval | ESLint core | Calls to eval |
| no-implied-eval | ESLint core | Strings passed to timers that are compiled like eval |
| no-new-func | ESLint core | Building functions from strings |
OWASP recommends linting with the typescript-eslint recommended sets plus no-eval, no-implied-eval and no-new-func for TypeScript projects.
Configuration details worth knowing
The react/no-danger rule has a customComponentNames option. By default it is empty. You can pass an array of component names, or the wildcard value, to apply the rule to custom components too. This matters when a design system component forwards a dangerous prop.
The vue/no-v-html rule is included in the eslint-plugin-vue recommended presets, according to its documentation. It also has an ignorePattern option that skips directives whose variable matches a pattern, for example names that start with html. All uses are forbidden by default.
Both rules' pages say that if you are certain the content is sanitized HTML you can switch the rule off. That is a decision to document, not a quiet disable comment.
A rollout plan
- Turn the rules on as warnings for one week to see the count.
- Triage the hits using the sink review table.
- Fix or wrap the legitimate ones in a single helper that sanitizes, and allow the rule there with a comment explaining why.
- Promote the rule to an error so new uses fail the build.
- Require review for any new disable comment, by code owners.
What lint cannot see
Static rules inspect syntax. They do not know where a value came from. A call that passes a constant is flagged the same as one that passes a comment from a stranger. They also miss sinks hidden in dependencies, URL attributes such as href, and server side template injection. Pair lint with code scanning, dependency scanning and runtime controls like a content security policy.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how a scan reports findings with how a lint rule reports a hit.
Safeguard's free scan at gold.safeguard.sh/scan covers the dependency side, which lint does not.
Quick check
Should I disable react/no-danger for sanitized content?
The rule docs allow it when you are certain the content is sanitized. Limit the disable to one helper so it is easy to audit.
Do these rules catch href problems?
Not by themselves. They target specific props and directives, so URL validation needs its own check.
Sources
- eslint-plugin-react no-danger
- eslint-plugin-vue no-v-html
- OWASP JavaScript and TypeScript Security Cheat Sheet
Last reviewed: 19 October 2026.
