A general linter such as ESLint is not a SAST tool by default. Its documentation states its goal as making code consistent and avoiding bugs. Security scanning for JavaScript and TypeScript needs rules written for security, ideally with data flow analysis from user input to dangerous functions.
Linter versus SAST
| Linter | SAST scanner | |
|---|---|---|
| Main goal | Consistency, avoiding bugs | Finding exploitable flaws |
| Typical rules | Unused variables, undefined names | Injection, unsafe HTML output, path handling |
| Data flow tracking | Rare | Common in deeper tools |
| Output for security teams | Warnings per file | Findings with severity and trace |
ESLint is pluggable, and every rule is a plugin, so security rules can be added. That makes it a useful early check, but a rule set is not the same as analysis that follows tainted data across files.
What JavaScript SAST should cover
- Cross site scripting through unsafe DOM writes and template output.
- Injection into shell commands, database queries and eval style functions.
- Prototype pollution patterns when merging objects from input. See prototype pollution prevention.
- Path traversal when building file paths from input.
- Hardcoded tokens in front end bundles.
TypeScript specifics
TypeScript types are erased at runtime. A value typed as a string can still contain anything an attacker sends, so type annotations are not validation. A scanner should treat parsed request bodies as untrusted regardless of declared types, and you still need runtime validation at the edge.
Steps to adopt
- Keep the linter for quality. Add security rules to it as a first layer.
- Add a SAST scan in pull requests for taint analysis across files.
- Scan both source and build output when you ship bundles to browsers, so secrets in bundles are noticed.
- Triage by severity and by whether the input is user controlled.
- Add dependency scanning, since npm projects pull in many packages.
How Safeguard helps
Safeguard covers SBOM and dependency scanning, reachability analysis, and policies and gates that apply in pull requests. The free scan is a quick way to see your dependency findings.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how each finding carries a severity and a path, which plain lint warnings do not.
Quick check
Do TypeScript types protect against injection?
No. Types are removed at runtime and do not validate incoming data.
Can I just add security rules to my linter?
It is a good first layer. Deeper SAST adds data flow analysis across files.
Sources
- ESLint documentation, Getting started (fetched 19 October 2026): stated purpose and pluggable rules.
Last reviewed: 19 October 2026.
