security-pen-testing

---
name: security-pen-testing
description: Use when performing security audits, penetration testing, vulnerability scanning, or OWASP Top 10 checks — covers static analysis, dependency/secret scanning, and API testing.
category: Engineering
version: 1.0.0
tools: []
---

# Security Penetration Testing

Hands-on offensive security testing for finding vulnerabilities before attackers do — not compliance checking and not security-policy writing, but systematic vulnerability discovery through authorized testing across web applications, APIs, infrastructure, and the software supply chain.

## Prerequisites

All testing described here assumes **written authorization** from the system owner — a signed scope-of-work or rules-of-engagement document, obtained before starting. Unauthorized testing is illegal under the CFAA and equivalent laws worldwide.

## OWASP Top 10 Systematic Audit

Work the audit checklist by category:

| # | Category | Key Tests |
|---|----------|-----------|
| A01 | Broken Access Control | IDOR, vertical escalation, CORS, JWT claim manipulation, forced browsing |
| A02 | Cryptographic Failures | TLS version, password hashing, hardcoded keys, weak PRNG |
| A03 | Injection | SQLi, NoSQLi, command injection, template injection, XSS |
| A04 | Insecure Design | Rate limiting, business-logic abuse, multi-step flow bypass |
| A05 | Security Misconfiguration | Default credentials, debug mode, security headers, directory listing |
| A06 | Vulnerable Components | Dependency audit (npm/pip/go), EOL checks, known CVEs |
| A07 | Auth Failures | Brute force, session-cookie flags, session invalidation, MFA bypass |
| A08 | Integrity Failures | Unsafe deserialization, SRI checks, CI/CD pipeline integrity |
| A09 | Logging Failures | Auth-event logging, sensitive data in logs, alerting thresholds |
| A10 | SSRF | Internal IP access, cloud metadata endpoints, DNS rebinding |

Every finding gets remediation steps and a CVSS score.

## Static Analysis

Reference tools and their role: CodeQL for custom queries tuned to project-specific patterns, Semgrep for rule-based scanning with auto-fix, and language-specific security linters (e.g. `eslint-plugin-security`, `eslint-plugin-no-unsanitized`) for JS/TS. Key patterns to hunt: SQL injection via string concatenation, hardcoded JWT secrets, unsafe YAML/pickle deserialization, and missing security middleware (e.g. an Express app without Helmet).

## Dependency Vulnerability Scanning

Ecosystem audit commands: `npm audit`, `pip audit`, `govulncheck ./...`, `bundle audit check`. CVE triage workflow: **collect** (run the ecosystem audit tool, aggregate findings) → **deduplicate** (group by CVE ID across direct and transitive dependencies) → **prioritize** (critical + exploitable + reachable = fix immediately) → **remediate** (upgrade, patch, or apply a compensating control) → **verify** (rerun the audit to confirm the fix and update lock files).

## Secret Scanning

Reference tools: TruffleHog (git history + filesystem scanning) and Gitleaks (regex-based with custom rules). Integration points: pre-commit hooks and a CI/CD gate (e.g. a GitHub Action running TruffleHog on every push). Configure custom rules and allowlists (AWS keys, API keys, private-key headers, with exceptions for known test fixtures) to keep the signal-to-noise ratio usable.

## API Security Testing

**Authentication bypass:** JWT manipulation (changing `alg` to `none`, RS256-to-HS256 confusion, modifying claims like `role: "admin"` or `exp: 9999999999`); session fixation (check whether the session ID changes after authentication).

**Authorization flaws:** IDOR/BOLA (swap resource IDs across every endpoint — test read, update, delete across different users' data); BFLA (a regular user probes admin endpoints, expecting 403); mass assignment (add privileged fields like `role` or `is_admin` to update request bodies).

**Rate limiting and GraphQL:** rapid-fire requests to auth endpoints, expecting a 429 after a threshold; for GraphQL, verify introspection is disabled in production, and test query-depth attacks and batch mutations that could bypass rate limits.

## Web Vulnerability Testing

| Vulnerability | Key Tests |
|--------------|-----------|
| XSS | Reflected (script/img/svg payloads), Stored (persistent fields), DOM-based (`innerHTML` + `location.hash`) |
| CSRF | Replay without token (expect 403), cross-session token replay, check SameSite cookie attribute |
| SQL Injection | Error-based (`' OR 1=1--`), union-based enumeration, time-based blind (`SLEEP(5)`), boolean-based blind |
| SSRF | Internal IPs, cloud metadata endpoints (AWS/GCP/Azure), IPv6/hex/decimal encoding bypasses |
| Path Traversal | `../../../etc/passwd`, URL encoding, double-encoding bypasses |

## Infrastructure Security

Cloud storage: check S3 bucket public access, bucket policies, and ACLs. HTTP security headers: verify HSTS, a CSP without `unsafe-inline`/`unsafe-eval`, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy are all present. TLS configuration: enumerate ciphers and reject TLS 1.0/1.1, RC4, 3DES, and export-grade ciphers. Port scanning: flag dangerous open ports such as FTP/21, Telnet/23, Redis/6379, MongoDB/27017.

## Pen Test Report Generation

Structure findings as a list of objects, each with: title, severity, cvss_score, cvss_vector, category (mapped to an OWASP Top 10 category), description, evidence (request/response), impact, remediation, and references (e.g. a CWE link). Example: a critical SQL injection in a login endpoint scores CVSS 9.8 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`), maps to A03:2021, and its remediation is "use parameterized queries, replace string concatenation with prepared statements."

**Report structure:** Executive Summary (business impact, overall risk, top 3 findings) → Scope (what was tested/excluded, dates) → Methodology (tools, black/gray/white-box approach) → Findings Table (sorted by severity with CVSS scores) → Detailed Findings (description, evidence, impact, remediation per item) → Remediation Priority Matrix (effort vs. impact) → Appendix (raw tool output, full payload lists).

## Responsible Disclosure Workflow

Responsible disclosure is mandatory for any vulnerability found during authorized testing. Standard timeline: report on day 1, follow up at day 7, status update at day 30, public disclosure at day 90 (accelerated 30-day and extended 120-day timelines apply in some programs). Key principles: never exploit beyond proof of concept, encrypt all communications, never access real user data, and document everything with timestamps.

## Workflows

**Quick security check (~15 min, pre-merge):** run the OWASP checklist at quick scope; scan dependencies for high-severity issues; check for secrets in recent commits; review HTTP security headers on the live/staging endpoint. Decision rule: any critical or high finding blocks the merge.

**Full penetration test (multi-day):** Day 1 reconnaissance — map the attack surface (endpoints, auth flows, third-party integrations), run the full-scope OWASP checklist, audit dependencies across all manifests, scan the full git history for secrets. Day 2 manual testing — authentication/authorization (IDOR, BOLA, BFLA), injection points (SQLi, XSS, SSRF, command injection), business-logic flaws, API-specific vulnerabilities (GraphQL, rate limiting, mass assignment). Day 3 infrastructure and reporting — cloud storage permissions, TLS configuration and security headers, port scan for unnecessary services, compile findings into structured JSON, generate the final report.

**CI/CD security gate:** on every PR run secret scanning (TruffleHog), dependency audit (`npm audit`, `pip audit`), and SAST (Semgrep with security-audit and OWASP-Top-Ten rulesets), plus a security-headers check on staging. Gate policy: block merge on critical/high findings, warn on medium, log low/info.

## Anti-Patterns

Testing in production without authorization — always get written permission and prefer staging/test environments. Ignoring low-severity findings — low findings compound; a chain of lows can become a critical exploit path. Skipping responsible disclosure — every vulnerability found must be reported through proper channels. Relying solely on automated tools — tools miss business-logic flaws, chained exploits, and novel attack vectors. Testing without a defined scope — scope creep leads to legal liability; document what is and isn't in scope. Reporting without remediation guidance — every finding must include actionable remediation steps. Storing evidence insecurely — pen-test evidence (screenshots, payloads, tokens) is sensitive and must be encrypted and access-restricted. One-time testing — security testing must be continuous, integrated into CI/CD, with periodic full assessments scheduled.