The hook
Most exploits in production codebases don't require novel research. They require a grep for `eval(` and a question about where the input came from. Static-analysis tooling has been catching the same small set of high-confidence patterns for two and a half decades — eval-with-user-input, dangerouslySetInnerHTML, exec-with-string, hard-coded credentials, unsafe deserialization, weak crypto primitives — and yet they keep showing up in modern code because the alternatives feel like more work in the moment. The bug class is well-understood; the persistence is operational. SAST works best when you accept that 95% of findings are signal, not noise, and treat the patterns as anti-patterns in code review.
Akkamitti hojjeta
Each language has a small list of constructs that turn data into code: `eval()`, `Function(string)`, `setTimeout(string)`, `pickle.loads()` in Python, `Marshal.load` in Ruby, `unserialize()` in PHP. Combined with user input, they're vulnerabilities. Each language also has framework-specific opt-out paths from safety: React's `dangerouslySetInnerHTML`, Vue's `v-html`, Angular's `bypassSecurityTrust*`. And every codebase has a long tail of hard-coded credentials — Stripe keys, Supabase service-role JWTs, internal API tokens — that survived from a 'temporary' commit in 2022. The SAST patterns we run are conservative: high-precision (low false-positive rate) at the cost of recall. We'd rather flag five real bugs than fifty maybe-bugs that lead the team to ignore the report.
The variants
eval / Function constructor
Direct code execution from a string. Combined with any user-controllable input, RCE-class. Even without user input, hard to refactor and harder to verify safe.
dangerouslySetInnerHTML / v-html
React / Vue opt-out from XSS-safe rendering. Sometimes legitimate (rendering server-sanitized markdown), more often a code smell.
Hard-coded service-role keys
Supabase service-role JWT, Firebase admin SDK creds, Stripe sk_live_, internal API tokens checked into source. The service-role key in client-side code bypasses RLS entirely.
Unsafe deserialization
Python `pickle.loads`, Ruby `Marshal.load`, Java native serialization, PHP `unserialize`. RCE on untrusted input — these classes have been exploited at industrial scale.
The blast radius
Tracks the pattern: eval is RCE, dangerouslySetInnerHTML is XSS, service-role-key embed is full database access bypassing RLS, hard-coded sk_live is billing takeover, unsafe deserialization is RCE. Each pattern catches one or more breaches per year somewhere in the industry; in your codebase, each is a potential incident waiting to be exploited.
// what fixvibe checks
What FixVibe checks
FixVibe repo scans look for high-confidence security patterns and dependency risk in source context. Reports identify the affected area and recommended fix. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
Adopt the patterns as anti-patterns in code review — make 'why does this code use eval?' a standard PR question. Add an ESLint config like `eslint-plugin-security`, `eslint-plugin-security-node`, or your language's equivalent (Bandit for Python, RuboCop's security cops for Ruby, Brakeman for Rails). Block secret leakage at commit time with gitleaks or trufflehog pre-commit hooks; the muscle memory of 'oh I shouldn't commit that' is more reliable than 'I should remember to remove it later.' Replace `dangerouslySetInnerHTML` with explicit DOMPurify calls when you need user-supplied HTML. Move all credentials into environment variables, fronted by a secret manager (Doppler, Vercel env, AWS Secrets Manager, HashiCorp Vault). For deserialization on untrusted input, use schema-validated JSON via Zod / Yup / Pydantic — never the language-native serialization formats.