security-pen-testing

intent

use this skill when you need to perform hands-on offensive security testing, vulnerability discovery, penetration testing, OWASP Top 10 audits, or supply chain security assessments. this is active vulnerability hunting through authorized testing, not compliance checking or policy writing. run this against web applications, APIs, infrastructure, and dependencies to find exploitable issues before attackers do. assumes you have written authorization from the system owner before starting any test.

inputs

authorization & scope

• signed scope-of-work or rules-of-engagement document from system owner (non-negotiable; unauthorized testing violates CFAA and equivalent laws)
• target system details: application URLs, API endpoints, IP ranges, third-party integrations
• testing environment: staging/test environment preferred; production testing only with explicit written approval
• timeline: testing dates, business hours windows, blackout periods

tools & runtime dependencies

• python 3.9+ with pip (for custom scripts)
• vulnerability_scanner.py: local script for OWASP checklist generation
• dependency_auditor.py: local script for CVE triage across npm/pip/go/ruby
• pentest_report_generator.py: local script for markdown/json report generation
• external tools: nmap (port scanning), testssl.sh or openssl (TLS audits), curl (header inspection)
• secret scanning tools: trufflehop (verified secret detection), gitleaks (regex-based scanning with custom rules)
• static analysis: CodeQL, Semgrep, eslint-plugin-security (language-specific)
• dependency audit CLI tools: npm audit, pip audit, govulncheck, bundle audit
• API testing: postman, burpsuite community, or curl for manual JWT/session testing

external connections & credentials

• git repository access (local file:// or https auth) for trufflehop/gitleaks secret scanning
• AWS account credentials (read-only IAM role) if testing S3 buckets or cloud metadata endpoints; set env var AWS_PROFILE
• target system network access (direct or VPN): ensure network connectivity and firewall rules allow test traffic
• GitHub Actions runner or CI/CD platform for automated gate integration: requires trufflesecurity/trufflehop action or equivalent
• staging/test environment database: populated with non-production data only

context & reference docs

• owasp_top_10_checklist.md: detailed test procedures, code patterns, remediation, CVSS scoring for each category
• attack_patterns.md: complete payloads for XSS, SQLi, SSRF, JWT manipulation, IDOR, GraphQL attacks, and bypass techniques
• responsible_disclosure.md: disclosure timelines (90-day standard, 30-day accelerated, 120-day extended), communication templates, CVE request process

procedure

1. obtain authorization and define scope

input: system owner contact, target application details, business requirements output: signed rules-of-engagement document, written scope statement

• contact system owner and request written authorization (email or formal agreement)
• define what is in-scope: application URLs, API endpoints, IP ranges, test environment names
• define what is out-of-scope: external third parties, production user data, compliance audits
• agree on testing window: dates, times, blackout periods, emergency contact
• store authorization document in secure, access-restricted location
• decision: if no written authorization obtained, stop. do not proceed to testing.

2. run automated OWASP checklist generation

input: target system type (web or api), scope level (quick or full) output: json findings file with automated vulnerability checklist

• run vulnerability_scanner.py with appropriate scope:

  python scripts/vulnerability_scanner.py --target web --scope full --json > findings-owasp.json
  

  (or --target api --scope quick for api-only rapid checks)
• review json output for: injection points, missing security headers, default credentials, directory listing, debug mode
• document tool version and execution timestamp in findings file

3. scan dependencies for known vulnerabilities

input: dependency manifests (package.json, requirements.txt, go.mod, gemfile) output: aggregated CVE list with severity, reachability status

• run ecosystem-native tools first:

  npm audit --json > npm-audit.json
  pip audit --json > pip-audit.json
  govulncheck ./... -json > go-vulns.json
  bundle audit check > ruby-audit.txt
  

• aggregate findings with custom auditor:

  python scripts/dependency_auditor.py --file package.json --severity critical --json > cve-triage.json
  

• for each CVE: record ID, affected version, severity (critical/high/medium/low), exploitability status, if code path is reachable in your app
• decision: if any critical or exploitable vulnerabilities found in reachable code, flag for immediate remediation before proceeding with manual testing

4. scan git history and filesystem for hardcoded secrets

input: git repository access, filesystem root directory, custom secret rules (.gitleaks.toml) output: secret findings json with context, line numbers, commit hashes

• scan git history for verified secrets:

  trufflehop git file://. --only-verified --json > secrets-git.json
  

• scan current filesystem:

  trufflehop filesystem . --json > secrets-filesystem.json
  

• optional: scan with gitleaks for regex patterns:

  gitleaks detect --source . --report-format json --report-path gitleaks-report.json
  

• review findings: aws keys, api tokens, private key headers, database credentials, jwt secrets
• for each secret: determine exposure scope (branch, commits, commits by whom), revoke immediately, rotate all dependent credentials
• decision: if verified secrets found in git history, escalate to platform/devops team immediately and revoke all exposed credentials before continuing

5. test authentication and authorization (APIs and web apps)

input: application endpoints, user credentials (test accounts with varying privilege levels), session storage mechanism output: json findings documenting auth flaws with proof-of-concept payloads

5a. jwt manipulation (APIs)

• obtain valid jwt token from login endpoint
• test algorithm confusion: decode token, change "alg" field to "none", replay (expect 401)
• test RS256-to-HS256 confusion: obtain public key, re-sign with HS256 using public key as secret, replay
• test claim modification: change "role" to "admin", extend "exp" to year 9999, re-sign with known secret, replay (if accepted, critical finding)
• test kid manipulation: if token uses "kid" (key id) header, try "./../../etc/passwd" or sql injection in kid value
• decision: if any token manipulation succeeds, document as "broken authentication" (A07) with cvss 8.1+

5b. session fixation and invalidation

• login with test user, capture session id/cookie
• logout, attempt to use same session id (expect 401)
• do not logout, change url to different user's resource (expect 403; if 200, idor finding, not auth)
• decision: if session not invalidated or reusable across users, flag as session management flaw

5c. brute force and rate limiting

• rapid-fire 10 requests to /api/login with wrong password
• check for 429 (too many requests), exponential backoff, account lockout, or ip blocking
• decision: if no rate limiting detected after 50+ attempts, flag as "broken authentication" with high severity

5d. multi-factor authentication bypass

• if mfa present: complete first factor, intercept second-factor request, try skipping or replaying first factor
• check if mfa can be disabled via user settings without re-authentication
• decision: if mfa can be bypassed or disabled, flag as critical

6. test authorization flaws (idor, bola, bfla, privilege escalation)

input: authenticated session(s) with different privilege levels (admin, user, guest if available), api endpoint documentation output: json findings documenting authorization bypasses with endpoint, method, payload

6a. idor/bola testing

• obtain valid request to /api/users/123/profile (resource id 123)
• systematically test id manipulation: change 123 to 124, 1, 999999, negative values, uuid manipulation
• test across all http methods: get (read), post (create for other user), put (update), delete
• test id encoding: url-encode (123 = %31%32%33), double-encode, use hex (0x7b), use array ([123])
• decision: if you read, update, or delete another user's resource without ownership check, idor finding (critical, cvss 7.5+)

6b. bfla (broken function level authorization)

• as regular user, attempt to access admin-only endpoints: /api/admin/users, /api/admin/reports, /api/settings/system
• expect 403 forbidden; if 200 with data or successful mutation, bfla finding
• test parameter escalation: add ?role=admin or admin=true to regular user requests
• decision: if regular user accesses admin functionality, critical authorization bypass (cvss 8.0+)

6c. mass assignment

• submit create/update request for regular resource (e.g., user profile)
• add privileged fields in payload: "role": "admin", "is_admin": true, "plan": "enterprise", "balance": 9999
• check if server silently accepts or applies unauthorized field values
• decision: if privileged fields are set via mass assignment, authorization flaw (medium-high depending on field sensitivity)

7. test injection vulnerabilities (sql, nosql, command, template, xpath)

input: application forms, api parameters, user input fields; database type (mysql, postgres, mongodb, etc.) output: json findings with payload, affected parameter, database response

7a. sql injection

• error-based: submit ' OR 1=1-- to text input (login email, search query)
• review error messages: if database syntax visible, error-based sqli confirmed
• union-based: craft ' UNION SELECT NULL,NULL,NULL-- (adjust null count to match columns)
• time-based blind: submit ' AND SLEEP(5)-- (postgres: pg_sleep(5)), measure response time; 5+ second delay confirms blind sqli
• boolean-based blind: submit ' AND 1=1-- (returns normal), then ' AND 1=2-- (returns different), confirm logic
• decision: if any injection technique succeeds, critical sqli (cvss 9.8, a03 category)

7b. nosql injection (mongodb, etc.)

• typical parameter: {"username": "admin"} becomes mongo query
• inject: {"username": {"$ne": null}} (not-equal-null bypass)
• or: submit {$or: [{}, {a: 1}]} in json body
• test command injection within nosql: {$where: "this.username == 'admin'"} if server allows
• decision: if nosql syntax accepted in user input, critical injection

7c. command injection

• forms that run os commands (ping, nslookup, imagemagick): submit ; cat /etc/passwd or | whoami
• use separators: ;, |, ||, &, &&, $(...), `...`
• decision: if shell commands execute, critical rce

7d. template injection

• web frameworks with template rendering (jinja2, handlebars, etc.): inject {{7*7}}, ${7*7}, <%= 7*7 %>
• if output shows 49, template injection confirmed
• escalate: attempt {{config.items()}} (flask), {{_self.env.registerUndefinedFilterCallback("system")}} (twig rce)
• decision: if templates execute arbitrary code, critical rce

8. test cross-site scripting (xss)

input: web forms, url parameters, api responses rendered in browser output: json findings with payload, injection point, evidence (screenshot or network log)

8a. reflected xss

• submit <script>alert(1)</script> to search box, url parameter, or form field
• check if unescaped output appears in html response
• if script tag escaped, try context-aware payloads: "><svg onload=alert(1)> (html attribute context), '-(alert(1))-' (js string context)
• decision: if javascript executes in victim browser, xss confirmed (severity depends on impact: stealing cookies = high, defacement = medium)

8b. stored xss

• submit <img src=x onerror=alert(1)> to profile field, comment, forum post
• reload page or access as different user, check if payload persists and executes
• decision: if payload stored and executes for other users, critical stored xss

8c. dom-based xss

• identify dom sinks: innerHTML, eval, document.write, location, setTimeout with user input
• craft payload: #<img src=x onerror=alert(1)> (hash-based), /path?q=<img src=x onerror=alert(1)> (query param)
• check if javascript processes input and modifies dom without sanitization
• decision: if payload executes via dom manipulation, dom xss finding

9. test api-specific vulnerabilities

input: api specification (swagger/openapi), api endpoint list, session tokens output: json findings for rate limiting, graphql, mass assignment

9a. rate limiting bypass

• send 100 requests/second to auth endpoint, mutation endpoint, or password reset
• check for 429 response or rate limit headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset)
• test bypass techniques: add x-forwarded-for headers with rotating ips, use different user agents, distribute across multiple connections
• decision: if no rate limiting or easily bypassed, flag as insecure design (a04) or broken auth (a07)

9b. graphql vulnerabilities

• query introspection: send {__schema{types{name}}} (if introspection enabled, high finding; disable in prod)
• test query depth: deeply nested query {a{b{c{d{e{f{g{h{i{j{k{...; if no depth limit, ddos risk
• test batch mutations: submit array of mutations [mutation1, mutation2, mutation3...]; if all execute without rate limit per mutation, bypass
• decision: if introspection enabled, critical (attacker maps api); if depth unlimited, dos risk; if batch mutations bypass rate limits, high

10. test business logic flaws

input: application workflows (account creation, payment, order, password reset), documentation of expected behavior output: json findings documenting logic bypass with reproduction steps

• test multi-step flow bypass: create account with 5 steps; attempt to skip to step 4 directly (expect 403)
• test state machine bypass: order workflow is pending -> processing -> shipped; attempt to submit state back to pending after shipped
• test price/quantity manipulation: add item to cart at $10, change quantity to negative or fractional values, check final price
• test authorization in workflows: invite user to project (2-step: send invite, accept); attempt to accept invite sent to different user
• decision: if business logic can be circumvented to gain financial benefit, unauthorized access, or privilege escalation, business logic flaw (severity varies, typically medium-high)

11. test cross-site request forgery (csrf)

input: authenticated session, state-changing endpoints (post/put/delete) output: json findings documenting csrf vulnerability

• identify csrf tokens: check for request-id, csrf-token, x-csrf-token headers or form fields
• if tokens exist, replay request without token (expect 403)
• if tokens exist, test token reuse: copy token from request A, use in request B (expect 403 if properly scoped)
• if no tokens: create html form that auto-submits to state-changing endpoint (e.g., change password), open in another tab
• check sameSite cookie attribute: if sameSite=none, csrf risk (should be sameSite=strict or sameSite=lax for state changes)
• decision: if state-changing requests succeed without valid csrf token, csrf vulnerability (medium severity)

12. test ssrf (server-side request forgery)

input: endpoints that fetch external resources (image upload, url preview, webhook, import) output: json findings documenting ssrf with payloads

• test internal ips: submit http://127.0.0.1:8080, http://192.168.1.1, http://localhost/admin
• test cloud metadata: submit http://169.254.169.254/latest/meta-data/iam/security-credentials/ (aws), http://metadata.google.internal/ (gcp), http://169.254.169.254/metadata/identity/oauth2/access_token (azure)
• test bypass encoding: hex-encoded ip (http://0x7f000001), octal (http://0177.0.0.1), decimal (http://2130706433), ipv6 (http://[::1])
• test dns rebinding: subdomain that resolves to internal ip
• decision: if internal resource fetched or cloud metadata accessed, critical ssrf (cvss 8.6+, a10)

13. test path traversal and file inclusion

input: endpoints with file parameters (download, preview, include) output: json findings with payload and accessed file path

• test path traversal: submit ../../etc/passwd to download endpoint
• test encoding bypass: url-encode (..%2f..%2fetc%2fpasswd), double-encode (..%252f..%252fetc%252fpasswd), null byte (if old php: ....//....//etc/passwd%00)
• test case sensitivity: if blacklist blocks ../, try ..\\ or ..\/
• test null terminator (php < 5.3.4): submit etc/passwd%00.pdf to read /etc/passwd as pdf
• decision: if arbitrary file read or code execution via include, critical finding (a03 injection or rce)

14. inspect http security headers

input: target domain/app running on https output: json findings listing missing or misconfigured headers

• query headers:

  curl -sI