SuperAPI AI Directory

security-audit-standard

Security & auditing

View repository

Updated 10-13 15:13

About this skill

Security Audit Standard

Methodology derived from production security audits.

Audit Process

Phase 1: Secret Scanning

Scan for hardcoded credentials in tracked source files.

Targets:
- API keys, tokens, passwords in source (not .env)
- Webhook URLs with tokens
- Database connection strings
- Private keys, certificates
- obfstr!() usage (Rust): still in binary, just obfuscated

Check patterns:

grep -rn "sk-" "pk_" "ghp_" "token" "secret" "password" "apikey"
grep -rn "https://discord.com/api/webhooks/"
grep -rn "https://hooks.slack.com/"
grep -rn "mongodb://" "postgresql://" "redis://"

Verify .gitignore covers: .env*, *.pem, *.key, credentials*, secrets*, auth*.json, config.json (if it contains secrets).

Phase 2: Input Validation

For every endpoint/command that accepts user input:

  1. Where does input enter the system? (HTTP body, query params, WebSocket messages, IPC commands, CLI args, file uploads)
  2. Is it validated before processing? (type checking, length limits, format validation)
  3. Is it sanitized before output? (HTML escaping, SQL parameterization)
  4. Are error messages safe? (no stack traces, no internal paths, no credential hints)

Checklist:

  • SQL queries use parameterized statements (never string concatenation)
  • HTML output is escaped (no raw user content in templates)
  • File paths are validated (no path traversal ../)
  • JSON parsing has try/catch (malformed input doesn't crash)
  • Integer inputs have range checks (no overflow/underflow)
  • String inputs have max length limits
  • File uploads validate type, size, and content (not just extension)

Phase 3: Authentication & Authorization

  • Passwords hashed with bcrypt/argon2 (not MD5/SHA1)
  • JWT tokens have expiration (exp claim)
  • JWT secret is strong (>32 bytes, not "secret")
  • Session tokens rotated on privilege change
  • OAuth flows validate state parameter (CSRF protection)
  • OAuth flows validate all required response fields
  • API keys transmitted via headers (not query params: logged in access logs)
  • Admin endpoints require authentication + authorization
  • Rate limiting on login/auth endpoints (brute force protection)
  • Account lockout after N failed attempts

Phase 4: Data Protection

  • Secrets stored in OS keychain / encrypted store (not plain files)
  • Sensitive data not logged (mask tokens, passwords, PII)
  • HTTPS enforced (no mixed content)
  • CORS configured restrictively (not * in production)
  • CSP headers set (script-src, connect-src restricted)
  • Cookies: HttpOnly, Secure, SameSite flags set
  • Temp files use unpredictable paths (tempfile crate, mkstemp)
  • Sensitive data cleared from memory after use

Phase 5: Dependency Audit

# Node.js
npm audit
pnpm audit

# Rust
cargo audit
cargo deny check

# Python
pip-audit
safety check

# Go
govulncheck ./...

Check for:

  • Known CVEs in dependencies
  • Outdated dependencies (major versions behind)
  • Abandoned packages (no commits in 2+ years)
  • Typosquat packages (similar names to popular packages)

Phase 5b: Supply Chain

Check Command / File Why
Lockfile committed package-lock.json, Cargo.lock, go.sum, Package.resolved Pin transitive dep versions
GitHub Actions pinned to SHA uses: actions/checkout@<sha> @v4 tag can be moved by attacker
Install scripts disabled in CI npm ci --ignore-scripts Prevents postinstall RCE
Provenance or signing npm publish --provenance, sigstore for releases Lets consumers verify origin
Allow-list of registries .npmrc registry=, cargo index Blocks dependency confusion
  • Typosquat packages (similar names to popular packages)

Phase 6: Infrastructure

  • No debug endpoints in production
  • Error pages don't leak stack traces
  • Server headers don't expose technology versions
  • Rate limiting on all public endpoints
  • Process runs as non-root user
  • File permissions are restrictive (600 for secrets, 755 for executables)
  • Firewall rules minimize exposed ports
  • TLS 1.2+ enforced (no SSLv3, TLS 1.0/1.1)
  • Database not accessible from public internet

OWASP Top 10 Quick Check

# Vulnerability Check
A01 Broken Access Control Every endpoint verifies auth + authz?
A02 Cryptographic Failures Using strong algorithms? Secrets encrypted at rest?
A03 Injection All inputs parameterized/escaped?
A04 Insecure Design Threat model exists? Security requirements documented?
A05 Security Misconfiguration Default creds removed? Error handling configured?
A06 Vulnerable Components Dependencies audited? No known CVEs?
A07 Auth Failures Brute force protected? MFA available?
A08 Data Integrity Failures Updates verified (checksums)? CI/CD secured?
A09 Logging Failures Security events logged? Logs don't contain secrets?
A10 SSRF Server-side requests validated? Internal URLs blocked?

Tauri-Specific Security

  • CSP in tauri.conf.json restricts script-src and connect-src
  • IPC commands are enum-constrained (no arbitrary command execution)
  • dangerous-api features disabled unless explicitly needed
  • File system access scoped to app directories
  • Shell commands never constructed from user input

Audit Report Format

# Security Audit: [Project Name]
Date: YYYY-MM-DD

## Summary
- Critical: N findings
- High: N findings
- Medium: N findings
- Low: N findings

## Critical Findings

### [CRIT-01] Hardcoded API key in tracked source
- **Location**: `src/config.json:15`
- **Risk**: Key exposure if repo made public or cloned
- **Fix**: Move to .env, add to .gitignore, rotate key
- **Effort**: 5 minutes

## High Findings
...

## Recommendations
1. [Priority-ordered action items]

Severity levels:

  • Critical: Immediate exploitation possible, data breach risk
  • High: Exploitable with some effort, significant impact
  • Medium: Requires specific conditions, moderate impact
  • Low: Minor risk, defense-in-depth improvement