security-and-owasp

name	security-and-owasp
description	Apply secure coding practices based on OWASP Top 10 and security-by-default principles. Use when reviewing, writing, or auditing code for security vulnerabilities. Covers broken access control, injection prevention, cryptographic failures, secret management, authentication, dependency vulnerabilities, and SSRF. Always choose the more secure option and explain the reasoning.

Secure Coding and OWASP Guidelines

Apply least privilege, secure secrets management, parameterised queries, secure defaults, and dependency vulnerability checks.

Primary Directive

Ensure all code generated, reviewed, or refactored is secure by default. Operate with a security-first mindset. When in doubt, choose the more secure option and explain the reasoning.

1. Access Control & SSRF (OWASP A01, A10)

• Least Privilege: Default to most restrictive permissions; grant only what is explicitly required
• Deny by Default: All access control decisions follow deny-by-default pattern
• SSRF Prevention: Validate all user-provided URLs with a strict allow-list (host, port, path)
• Path Traversal: Sanitise all file path inputs; use APIs that build paths securely

2. Cryptographic Failures (OWASP A02)

• Password Hashing: Use Argon2 or bcrypt — never MD5 or SHA-1
• Data in Transit: Default to HTTPS for all network requests
• Data at Rest: Use AES-256 for sensitive data encryption
• Secret Management: Never hardcode secrets — read from environment variables or a secrets manager

# ✅ GOOD — load from environment
api_key = os.environ["API_KEY"]

# ❌ BAD — hardcoded secret
api_key = "sk_this_is_a_very_bad_idea_12345"

3. Injection Prevention (OWASP A03)

• SQL: Always use parameterised queries (prepared statements) — never string concatenation
• OS Commands: Use shlex in Python to sanitise command-line inputs and prevent shell injection
• XSS: Use context-aware output encoding; prefer .textContent over .innerHTML; sanitise with DOMPurify when HTML is necessary

# ✅ GOOD — parameterised query
cursor.execute("SELECT * FROM tracks WHERE artist = ?", (artist_name,))

# ❌ BAD — string concatenation
cursor.execute(f"SELECT * FROM tracks WHERE artist = '{artist_name}'")

4. Security Misconfiguration & Vulnerable Dependencies (OWASP A05, A06)

• Disable verbose error messages and debug features in production
• For web apps, add security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options
• When adding libraries, specify the latest stable version
• Regularly run vulnerability scanners: pip-audit, npm audit, Snyk

5. Authentication Failures (OWASP A07)

• Generate a new session identifier after login (prevents session fixation)
• Set session cookies with HttpOnly, Secure, and SameSite=Strict
• Implement rate limiting and account lockout after repeated failed attempts

6. Data Integrity (OWASP A08)

• Avoid deserialising data from untrusted sources without validation
• Prefer JSON over Pickle in Python for serialisation
• Implement strict type checking when deserialisation is necessary

Code Review Behaviour

When identifying a security vulnerability:

1. Provide corrected code
2. Explain the specific risk (e.g., "Using a parameterised query here to prevent SQL injection")
3. Reference the OWASP category when relevant
4. Suggest tooling to catch the class of issue automatically (linters, scanners)

General Principles

• Be explicit: when suggesting security-mitigating code, state what attack is being prevented
• Document security decisions with comments
• Treat all user input as untrusted until validated
• Apply defence-in-depth: multiple security layers are better than relying on one control