Problem
Native regex rules are fast and zero-dependency, but they lack awareness of framework-specific safe patterns. This leads to systematic false positives for teams using modern libraries that have built-in security (parameterized queries, type-safe configs, etc.).
Current State
Right now, consumers have two options:
- Baseline — suppress findings file-by-file. Works but is noisy and requires periodic regeneration.
- Ignore comments —
// owasp-wtf-ignore on every affected line. Doesn't scale for 100+ findings.
Proposed Feature: Framework-aware safe-pattern allowlist
Add a config section (or auto-detection) for known-safe patterns from popular libraries:
Database / Query libraries
| Library |
Safe pattern |
Why |
@neondatabase/serverless |
sql\SELECT ... ${var}`` |
Tagged template → parameterized query |
drizzle-orm |
db.select().from(users).where(eq(...)) |
Fluent API, never string-concatenates |
kysely |
db.selectFrom('users').where('id', '=', id) |
Type-safe query builder |
prisma |
prisma.user.findMany({ where: { id } }) |
ORM with parameterization |
pg |
client.query('SELECT $1', [id]) |
Positional parameters |
Auth / Config
| Library |
Safe pattern |
Why |
privy |
PrivyProvider, usePrivy() |
Wallet auth, no secret exposure |
next-auth |
NextAuth() config objects |
Framework-managed secrets |
Static content
| Pattern |
Safe pattern |
Why |
| Next.js JSON-LD |
dangerouslySetInnerHTML with JSON.stringify(faqJsonLd) |
Static structured data, no user input |
| Docusaurus/Markdown |
Static HTML in MDX |
Build-time content |
Implementation Options
Option 1: Hardcoded library detection in native rules
Add framework-aware logic directly into native rule files. Pro: works out of box. Con: requires releases for new libraries.
Option 2: Configurable allowlist in ~/.owasp-wtf/config.json
Pro: consumer-controlled, no release needed. Con: requires manual setup.
Option 3: Auto-detect from package.json + heuristics
Read package.json dependencies. If @neondatabase/serverless is present, automatically skip sql\...`from SQL injection. Ifnextis present, allowdangerouslySetInnerHTMLwithJSON.stringifyin.tsx` files.
Pro: zero config. Con: more complex, may have edge cases.
Preference
Option 3 for top 10 libraries + Option 2 as escape hatch for everything else. This gives the best out-of-box experience while preserving flexibility.
Reported from Dial-WTF/x402-dial production rollout — PR #120
Problem
Native regex rules are fast and zero-dependency, but they lack awareness of framework-specific safe patterns. This leads to systematic false positives for teams using modern libraries that have built-in security (parameterized queries, type-safe configs, etc.).
Current State
Right now, consumers have two options:
// owasp-wtf-ignoreon every affected line. Doesn't scale for 100+ findings.Proposed Feature: Framework-aware safe-pattern allowlist
Add a config section (or auto-detection) for known-safe patterns from popular libraries:
Database / Query libraries
@neondatabase/serverlesssql\SELECT ... ${var}``drizzle-ormdb.select().from(users).where(eq(...))kyselydb.selectFrom('users').where('id', '=', id)prismaprisma.user.findMany({ where: { id } })pgclient.query('SELECT $1', [id])Auth / Config
privyPrivyProvider,usePrivy()next-authNextAuth()config objectsStatic content
dangerouslySetInnerHTMLwithJSON.stringify(faqJsonLd)Implementation Options
Option 1: Hardcoded library detection in native rules
Add framework-aware logic directly into native rule files. Pro: works out of box. Con: requires releases for new libraries.
Option 2: Configurable allowlist in
~/.owasp-wtf/config.json{ "rules": { "A03-SQL-INJECTION": { "safeTemplateTags": ["sql", "db"] }, "A03-XSS": { "safePatterns": [ { "file": "*.tsx", "context": "JSON.stringify(.*JsonLd)" } ] }, "A02-HARDCODED-SECRET": { "skipInTypes": true, "placeholderPrefixes": ["YOUR_", "REPLACE_", "EXAMPLE_"] } } }Pro: consumer-controlled, no release needed. Con: requires manual setup.
Option 3: Auto-detect from
package.json+ heuristicsRead
package.jsondependencies. If@neondatabase/serverlessis present, automatically skipsql\...`from SQL injection. Ifnextis present, allowdangerouslySetInnerHTMLwithJSON.stringifyin.tsx` files.Pro: zero config. Con: more complex, may have edge cases.
Preference
Option 3 for top 10 libraries + Option 2 as escape hatch for everything else. This gives the best out-of-box experience while preserving flexibility.
Reported from Dial-WTF/x402-dial production rollout — PR #120