Owasp Security

OWASP Security Best Practices

Apply these security standards when writing or reviewing code.

For deeper material, load on demand:

• references/language-security-quirks.md: language-specific pitfalls and unsafe/safe patterns for 20 languages (JS/TS, Python, Java, C#, PHP, Go, Ruby, Rust, Swift, Kotlin, C/C++, Scala, R, Perl, Bash, Lua, Elixir, Dart, PowerShell, SQL). Read it when reviewing code in a specific language.
• references/llm-agentic-security.md: OWASP Top 10 for LLM Applications (2025) and Agentic AI security (2026), with checklists and code patterns. Read it when the code calls an LLM, builds a RAG pipeline, or wires up an AI agent with tools.

Quick Reference: OWASP Top 10:2025

Security Code Review Checklist

When reviewing code, check for these issues:

Input Handling

• All user input validated server-side
• Using parameterized queries (not string concatenation)
• Input length limits enforced
• Allowlist validation preferred over denylist

Authentication & Sessions

• Passwords hashed with Argon2/bcrypt (not MD5/SHA1)
• Session tokens have sufficient entropy (128+ bits)
• Sessions invalidated on logout
• MFA available for sensitive operations

Access Control

• Check for framework-level auth middleware (e.g. Next.js middleware.ts, proxy.ts, Express middleware) before flagging missing per-route auth
• Authorization checked on every request
• Using object references the user cannot manipulate
• Deny by default policy
• Privilege escalation paths reviewed

Data Protection

• Sensitive data encrypted at rest
• TLS for all data in transit
• No sensitive data in URLs/logs
• Secrets in environment/vault (not code)

Error Handling

• No stack traces exposed to users
• Fail-closed on errors (deny, not allow)
• All exceptions logged with context
• Consistent error responses (no enumeration)

Secure Code Patterns

SQL Injection Prevention

# UNSAFE
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# SAFE
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

Command Injection Prevention

# UNSAFE
os.system(f"convert {filename} output.png")

# SAFE
subprocess.run(["convert", filename, "output.png"], shell=False)

Password Storage

# UNSAFE
hashlib.md5(password.encode()).hexdigest()

# SAFE
from argon2 import PasswordHasher
PasswordHasher().hash(password)

Access Control

# UNSAFE - No authorization check
@app.route('/api/user/<user_id>')
def get_user(user_id):
    return db.get_user(user_id)

# SAFE - Authorization enforced
@app.route('/api/user/<user_id>')
@login_required
def get_user(user_id):
    if current_user.id != user_id and not current_user.is_admin:
        abort(403)
    return db.get_user(user_id)

Error Handling

# UNSAFE - Exposes internals
@app.errorhandler(Exception)
def handle_error(e):
    return str(e), 500

# SAFE - Fail-closed, log context
@app.errorhandler(Exception)
def handle_error(e):
    error_id = uuid.uuid4()
    logger.exception(f"Error {error_id}: {e}")
    return {"error": "An error occurred", "id": str(error_id)}, 500

Fail-Closed Pattern

# UNSAFE - Fail-open
def check_permission(user, resource):
    try:
        return auth_service.check(user, resource)
    except Exception:
        return True  # DANGEROUS!

# SAFE - Fail-closed
def check_permission(user, resource):
    try:
        return auth_service.check(user, resource)
    except Exception as e:
        logger.error(f"Auth check failed: {e}")
        return False  # Deny on error

ASVS 5.0 Key Requirements

Level 1 (All Applications)

• Passwords minimum 12 characters
• Check against breached password lists
• Rate limiting on authentication
• Session tokens 128+ bits entropy
• HTTPS everywhere

Level 2 (Sensitive Data)

• All L1 requirements plus:
• MFA for sensitive operations
• Cryptographic key management
• Comprehensive security logging
• Input validation on all parameters

Level 3 (Critical Systems)

• All L1/L2 requirements plus:
• Hardware security modules for keys
• Threat modeling documentation
• Advanced monitoring and alerting
• Penetration testing validation

Deep Security Analysis Mindset

When reviewing any language, think like a senior security researcher:

1. Memory Model: How does the language handle memory? Managed vs manual? GC pauses exploitable?
2. Type System: Weak typing = type confusion attacks. Look for coercion exploits.
3. Serialization: Every language has a native-object deserializer. All are dangerous with untrusted input.
4. Concurrency: Race conditions, TOCTOU, atomicity failures specific to the threading model.
5. FFI Boundaries: Native interop is where type safety breaks down.
6. Standard Library: Historic CVEs in std libs (Python urllib, Java XML, Ruby OpenSSL).
7. Package Ecosystem: Typosquatting, dependency confusion, malicious packages.
8. Build System: Makefile/gradle/npm script injection during builds.
9. Runtime Behavior: Debug vs release differences (Rust overflow, C++ assertions).
10. Error Handling: How does the language fail? Silently? With stack traces? Fail-open?

For any language not covered in the reference file: research its specific CWE patterns, CVE history, and known footguns. The examples are entry points, not complete coverage.

When to Apply This Skill

Use this skill when:

• Writing authentication or authorization code
• Handling user input or external data
• Implementing cryptography or password storage
• Reviewing code for security vulnerabilities
• Designing API endpoints
• Building AI agent systems
• Integrating LLMs, RAG pipelines, or function-calling tools (read the LLM/agentic reference)
• Configuring application security settings
• Handling errors and exceptions
• Working with third-party dependencies
• Working in any language: apply the deep analysis mindset above and read the language-quirks reference for the language at hand