Code Security

Code Security

When to Use

• Write or review application code for common vulnerability classes (injection, XSS, auth, crypto, SSRF, XXE, deserialization)
• Review secrets handling, session/JWT patterns, and transport security in code
• Review Terraform, Kubernetes manifests, Dockerfiles, or GitHub Actions for security misconfigurations
• Proactively harden code that accepts user input, performs I/O, queries databases, or calls external URLs
• Map findings to CWE/OWASP categories and suggest concrete secure patterns

When NOT to Use

• Plan or execute authorized penetration tests, exploit chains, or red-team campaigns → ai-redteam, cybersecurity, penetration-tester, red-team-specialist
• Map controls to SOC 2, ISO 27001, or build audit evidence packages → compliance-engineer, compliance-specialist
• Deploy SIEM, IdP, KMS, WAF, or operate security tooling → information-security-engineer
• Configure CI/CD scanners, SBOM, OIDC, or pipeline gates without secure-coding review → devsecops
• Author YARA or malware detection rules → yara-rule-authoring
• General feature design, RFCs, or refactoring without a security lens → senior-software-engineer

Related skills

How to work

Modes

• Proactive — When writing or touching security-sensitive code (input, auth, files, DB, HTTP clients, crypto, IaC), check relevant categories without waiting for an explicit security ask.
• Reactive — When the user requests a security review, follow the review workflow in references/review_checklist_and_owasp_mapping.md.

Workflow

1. Identify language/stack and what the code does (input? DB? shell? XML? outbound HTTP? secrets? IaC?). 2. Load the matching reference(s) below; prioritize Critical then High impact. 3. Flag vulnerable patterns with CWE/OWASP labels; propose secure alternatives from references (language-specific examples live there). 4. For reviews, produce severity-ordered findings with file/line context and fix guidance.

Language priority (first checks)

When to load references

Detailed vulnerable/secure patterns and multi-language examples are in references/ (condensed from 28 upstream rule categories). Do not expect per-language copies of every rule in SKILL.md.

Quick prevention reference

Code security scope and workflow

Table of contents

1. Purpose and boundaries 2. Proactive vs reactive modes 3. Review workflow 4. Language priority table 5. Impact tiers 6. Evidence and reporting

Purpose and boundaries

This skill covers secure coding guidance and security-focused code review for application and infrastructure-as-code artifacts. It distills OWASP-oriented patterns across 15+ languages and common IaC formats.

In scope: identifying vulnerable patterns, recommending secure replacements, mapping to CWE/OWASP, prioritizing fixes by impact.

Out of scope: running authorized offensive engagements, compliance attestation, operating enterprise security tools, or replacing language-specific exploit development.

Proactive vs reactive modes

Proactive

Apply when the agent writes or edits code that:

• Accepts HTTP/query/body/header/cookie input
• Builds SQL, shell commands, file paths, or dynamic code
• Parses XML, deserializes objects, or fetches user-supplied URLs
• Handles passwords, tokens, API keys, or session state
• Defines Terraform, Kubernetes, Docker, or GitHub Actions resources

Check Critical categories first, then High, without waiting for the user to mention security.

Reactive

When the user asks for a security review, audit, or “is this safe?”:

1. Confirm scope (paths, languages, threat assumptions). 2. Follow review_checklist_and_owasp_mapping.md. 3. Return findings ordered by severity with CWE/OWASP tags and fix snippets.

Review workflow

scope → language/stack → data flows (sources/sinks) → category checklist → findings → fixes

Language priority table

When multiple issues exist, start with the rows that match the stack under review.

Impact tiers

Aligned with upstream rule categories (28 total, grouped here):

Evidence and reporting

Each finding should include:

• Location — file and line (or resource block in IaC)
• Issue — what can go wrong (one sentence)
• Severity — Critical / High / Medium / Low
• CWE — when applicable (e.g., CWE-89, CWE-79)
• OWASP — map to Top 10:2021 category (see review reference)
• Fix — concrete pattern (parameterize query, encode output, allowlist URL, etc.)

Avoid claiming exploitability without evidence; state assumptions (e.g., “if host is attacker-controlled”).

Cryptography, authentication, and session security

Table of contents

1. Hardcoded secrets 2. Cryptographic algorithms 3. Transport security (TLS) 4. JWT authentication 5. CSRF 6. Session management

CWE: 798 (hardcoded credentials), 327 (weak crypto), 319 (cleartext), 347 (JWT), 352 (CSRF)

---

Hardcoded secrets

Risk: Credentials in source, config committed to VCS, or logs—unauthorized access and difficult rotation.

Never hardcode: API keys, passwords, private keys, connection strings, signing secrets, webhook HMAC keys.

Secure patterns:

Review heuristics: High-entropy strings in code, AKIA, BEGIN PRIVATE KEY, password =, default credentials in samples.

On exposure: Rotate immediately; assume compromise if ever committed to git history.

---

Cryptographic algorithms

Avoid (broken or weak):

Key management: Generate keys in HSM/KMS; separate encryption keys per tenant where required; document rotation.

Do not roll custom crypto protocols — use established libraries and protocols (TLS, NaCl/libsodium, framework crypto).

---

Transport security (TLS)

Risk: Credentials and data exposed on the wire; MITM if verification disabled.

Requirements:

• HTTPS for all production traffic; HSTS for browser apps.
• Verify certificates — never disable TLS verification in production (rejectUnauthorized: false, verify=False).
• Modern TLS versions (1.2+; prefer 1.3); disable weak ciphers.
• Certificate pinning only when justified and maintained.

Review heuristics: http:// in production URLs, custom TrustManager that accepts all certs, curl -k.

---

JWT authentication

Risk: Forged or altered tokens if verification is missing or weak.

Checks:

Pattern: Use maintained libraries; always call verify with issuer/audience checks.

---

CSRF

Risk: Browser sends authenticated requests the user did not intend.

Mitigate state-changing operations (POST/PUT/PATCH/DELETE):

• Synchronizer token (CSRF token in form + cookie/header).
• SameSite cookies (Strict or Lax where compatible).
• Double-submit cookie pattern only with care (still prefer framework CSRF middleware).
• For APIs: avoid cookie auth without CSRF protection; use tokens with explicit client actions.

Not required for: Pure read-only GET with no side effects (still avoid sensitive data in GET URLs).

---

Session management

Coordinate with information-security-engineer for enterprise IdP/SSO patterns.

Deserialization, SSRF, and XXE

Table of contents

1. XML External Entity (XXE) 2. Insecure deserialization 3. Server-Side Request Forgery (SSRF)

CWE: 611 (XXE), 502 (deserialization), 918 (SSRF) OWASP Top 10:2021: A05 Security Misconfiguration (XXE/parser), A10 SSRF (2021 dedicated category)

---

XML External Entity (XXE)

Risk: Malicious XML references external entities—local file read, SSRF, DoS (billion laughs).

Vulnerable: Default XML parsers accepting DTDs/external entities (DocumentBuilderFactory, xml.etree on untrusted XML, libxml2 without hardening).

Secure patterns:

• Disable DTD and external entities on every parser that handles untrusted XML.
• Prefer JSON or safer formats when XML is not required.
• Use well-maintained libraries with secure defaults; validate schema size limits.

Review heuristics: parse(, DocumentBuilder, SAX/DOM without feature flags on user-uploaded XML.

---

Insecure deserialization

Risk: Attacker supplies serialized objects that execute code or bypass auth on deserialize.

High-risk APIs (never on untrusted input):

Secure patterns:

• Deserialize to limited DTOs with schema validation (JSON + strict types).
• Sign and encrypt serialized blobs if used; short TTL.
• Reject polymorphic type discriminators from untrusted sources.

Note: json.loads is not RCE by itself; risk is object graphs and gadget chains in native serializers.

---

Server-Side Request Forgery (SSRF)

Risk: Server fetches attacker-chosen URLs—internal services, cloud metadata (169.254.169.254), port scan, firewall bypass.

Common sinks: requests.get(url), axios.get(url), fetch(userUrl), image/PDF fetchers, webhook validators, import-from-URL features.

Secure patterns:

Incorrect pattern: User supplies full URL or hostname.

# Vulnerable
requests.get(f"https://{user_host}/api/...")

# Better: allowlist host
ALLOWED = {"api.example.com"}
if user_host not in ALLOWED:
    raise ValueError("host not allowed")
requests.get(f"https://{user_host}/api/...")

Cloud: Block access to instance metadata from app roles unless strictly required; use IMDSv2 on AWS.

Review heuristics: HTTP client first argument from request params; URL parsers that accept file://, gopher://, or redirects.

Infrastructure-as-code security

Table of contents

1. Terraform (AWS, Azure, GCP) 2. Kubernetes 3. Docker 4. GitHub Actions 5. IaC review checklist

Distilled from upstream rules: terraform-aws, terraform-azure, terraform-gcp, kubernetes, docker, github-actions.

---

Terraform (AWS, Azure, GCP)

Common misconfigurations

AWS patterns

# Prefer bucket-level encryption resource (provider v4+)
resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data.arn
    }
  }
}

• Avoid principal = "*" in trust policies without tight conditions.
• Use IAM roles for workloads—not long-lived access keys in Terraform outputs.

Azure / GCP (summary)

• Azure: Restrict public network access on storage/SQL; require TLS; managed identities over keys in templates.
• GCP: Avoid allUsers / allAuthenticatedUsers on buckets; enable uniform bucket-level access; least-privilege IAM bindings; VPC SC where required.

Review heuristics: 0.0.0.0/0, public = true, acl = "public-read", inline secrets, ignore_changes on security attributes.

---

Kubernetes

Pod and container security

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

Cluster hygiene

• Limit cluster-admin bindings; namespace-scoped roles.
• NetworkPolicies for east-west segmentation.
• Admission controllers (OPA/Gatekeeper, Kyverno) for policy-as-code.
• Pin images by digest in production; scan images in CI (devsecops).

---

Docker

FROM node:20-bookworm-slim
RUN useradd -r appuser
USER appuser
WORKDIR /app
COPY --chown=appuser:appuser . .

---

GitHub Actions

Script injection (CWE-78)

Risk: ${{ github.event.pull_request.title }} inside run: | executes as shell code.

Fix: Pass untrusted context values through env: and quote in shell:

- name: Check title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "$PR_TITLE"

pull_request_target (CWE-913)

Runs with base repo secrets. Checking out PR head and running npm install / build can execute attacker code with secret access.

• Avoid checkout + build of untrusted PR code on pull_request_target.
• Use pull_request for untrusted forks; separate approval for label-gated workflows.

Supply chain

• Pin actions to full commit SHA, not floating @v4 tags alone.
• Minimize permissions: to job needs (contents: read default).
• Do not echo secrets to logs; use OIDC to cloud over long-lived cloud keys in secrets.

---

IaC review checklist

1. Exposure — public endpoints, open SGs, anonymous bucket access 2. Identity — wildcard IAM, overbroad AssumeRole, static keys 3. Encryption — at rest and in transit defaults 4. Secrets — literals in HCL/YAML/env 5. Workload hardening — K8s securityContext, non-root containers 6. CI trust — injection surfaces, PR workflows, pinned actions

For org-wide guardrails (SCPs, OPA, CSPM), coordinate with information-security-engineer and cloud-security-engineer.

Injection and input validation

Table of contents

1. SQL injection 2. Command injection 3. Cross-site scripting (XSS) 4. Path traversal 5. Code injection 6. General input validation

CWE: 89 (SQLi), 78 (OS command), 79 (XSS), 22 (path traversal), 94 (code injection) OWASP Top 10:2021: A03 Injection, A07 Identification and Authentication Failures (XSS session impact)

---

SQL injection

Risk: Attacker manipulates query logic—read, modify, or delete data; sometimes RCE via DB features.

Vulnerable patterns: String concatenation, .format(), % formatting, f-strings, template literals embedding user data in SQL.

Secure patterns:

• Parameterized queries / prepared statements — bind values separately from SQL text.
• ORM query APIs — use bound parameters; avoid raw SQL with interpolation.
• Identifiers (table/column names) — allowlist only; never parameterize identifiers as strings from users.

Review heuristics: Search for execute(f"...", ` ...${var} , "SELECT" +, String.format` with SQL.

---

Command injection

Risk: Arbitrary OS command execution when user input reaches a shell.

Vulnerable patterns: os.system, subprocess with shell=True, exec of shell strings, backticks, Runtime.exec(String) with concatenation.

Secure patterns:

• Pass argument arrays without shell interpretation (subprocess.run([...], shell=False)).
• Use library APIs instead of CLI wrappers when possible.
• Strict allowlists for any unavoidable dynamic arguments.

---

Cross-site scripting (XSS)

Risk: Inject script into pages viewed by other users—session theft, defacement, malware.

Types: Reflected, stored, DOM-based.

Secure patterns:

• Context-aware output encoding (HTML, attribute, JS, URL contexts differ).
• Use framework defaults that auto-escape (react JSX text, template engines with escape).
• Content-Security-Policy as defense in depth.
• Never insert unsanitized HTML from users; if rich text is required, use a vetted sanitizer allowlist.

Review heuristics: innerHTML, dangerouslySetInnerHTML, document.write, unescaped template insertion in server HTML.

---

Path traversal

Risk: Read or write files outside intended directory via ../ or absolute paths.

Secure patterns:

• Resolve to canonical path and verify prefix under an allowed base directory.
• Reject .., NUL bytes, and alternate encodings in filenames.
• Use framework-safe APIs (send_file with safe root, Path.resolve() checks).

# Pattern: canonicalize then prefix-check
base = Path("/var/app/uploads").resolve()
target = (base / user_filename).resolve()
if not str(target).startswith(str(base)):
    raise ValueError("invalid path")

---

Code injection

Risk: Execute attacker-controlled code via eval, Function(), template engines, or dynamic import.

Vulnerable patterns: eval(user_input), new Function(user), server-side template injection, pickle/Marshal on untrusted bytes (see deserialization reference).

Secure patterns:

• Never evaluate user input as code.
• Use safe DSLs or strict JSON parsing with schema validation.
• Sandboxing is a last resort—not a substitute for avoiding dynamic execution.

---

General input validation

Apply at trust boundaries:

Prototype pollution (JavaScript): Validate object keys; avoid unsafe merge into prototypes (__proto__, constructor). Use Object.create(null) for maps when appropriate. CWE-1321.

Review checklist and OWASP mapping

Table of contents

1. Security review checklist 2. OWASP Top 10:2021 quick map 3. CWE quick reference 4. Medium and low impact 5. Finding template

---

Security review checklist

Use for reactive reviews. Check Critical before High.

Critical

• [ ] SQL injection — no dynamic SQL from user input; parameterized queries only
• [ ] Command injection — no shell with user data; argument arrays
• [ ] XSS — encoded output; no unsafe innerHTML / unescaped templates
• [ ] XXE — XML parsers hardened on untrusted XML
• [ ] Path traversal — canonical paths under allowlisted base
• [ ] Insecure deserialization — no pickle/Marshal/Java serialization on untrusted data
• [ ] Code injection — no eval/dynamic code on user input
• [ ] Hardcoded secrets — no keys/passwords in repo
• [ ] Memory safety (C/C++) — bounds checks; avoid unsafe string APIs

High

• [ ] Weak crypto — modern algorithms; no MD5/SHA1/DES/ECB for security
• [ ] TLS — verify certs; HTTPS in production
• [ ] SSRF — URL allowlists; no user-controlled hosts
• [ ] JWT — verify signature/alg/exp; no secrets in payload
• [ ] CSRF — tokens or SameSite on state-changing cookie auth
• [ ] Prototype pollution (JS) — safe object merge
• [ ] Unsafe functions — no gets, strcpy, reckless eval
• [ ] Terraform — encryption, least IAM, no public data stores
• [ ] Kubernetes — non-root, non-privileged, drop caps
• [ ] Docker — non-root user, no socket mount, pinned images
• [ ] GitHub Actions — no script injection; careful pull_request_target

Medium / Low (when time permits)

• [ ] ReDoS — catastrophic backtracking in user-supplied regex
• [ ] Race / TOCTOU — temp files, check-then-act
• [ ] Correctness — null derefs, error handling hiding failures

---

OWASP Top 10:2021 quick map

---

CWE quick reference

Full upstream index: 28 rule categories in source rules/_sections.md (not duplicated in this repo).

---

Medium and low impact

Regular expression DoS (ReDoS) — CWE-1333

Risk: User-supplied or attacker-influenced regex with catastrophic backtracking → CPU exhaustion.

Mitigations:

• Avoid nested quantifiers on overlapping alternations ((a+)+).
• Use regex timeouts (language-dependent) or RE2-style engines where appropriate.
• Prefer simple string operations or precompiled allowlists over complex regex on untrusted input.

Race conditions — CWE-367

Risk: TOCTOU between check and use (temp files, privilege checks).

Mitigations:

• Use atomic create (O_EXCL), secure temp APIs.
• File locks where appropriate; avoid predictable temp paths in shared /tmp.

Correctness with security impact

Logic bugs (off-by-one bounds, null checks, swallowed exceptions) can become vulnerabilities when they bypass auth or leak data. Flag when they affect security controls.

Low-priority categories (source rules)

Best practice, performance, maintainability — address when they directly weaken security (e.g., deprecated crypto API usage). Do not expand scope into general style review; defer to senior-software-engineer.

---

Finding template

### [Critical|High|Medium|Low] Title (CWE-XXX, OWASP A0X)

**Location:** `path:line` or resource name  
**Issue:** One sentence describing abuse scenario.  
**Evidence:** Code snippet or config excerpt (minimal).  
**Fix:** Specific secure pattern or config change.  
**References:** OWASP cheat sheet or internal reference file name.

Severity guidance: