pentest

Audit the security of your own project without breaking it.

This is a defensive, white-box, passive audit: it reads code and configuration, runs read-only scanners, observes HTTP responses, and maps everything to OWASP. It never exploits, brute-forces, floods, deletes, or exfiltrates. That is the whole point: you get the findings a pentest would open with, safely, on code you own.

Reply in the user's language. Write the report in the user's language.

Authorization first

Do not start until one of these is true:

• The target is the current project checkout (code you can read), or
• The user gives an explicit target (repo path or URL) plus confirmation they own it or may test it ("é meu", "tenho autorização", staging they own).

If the target is a third-party site, API, or app the user does not own, stop and explain: test only with written authorization. Offer to audit their own code instead.

Never test a target the user does not own. Never run active payloads (SQLi/XSS fuzzing, auth bypass attempts, SSRF callbacks) without the user explicitly choosing active mode for their own staging environment. Default is passive.

Three tiers

Classify every finding before reporting it:

references/checklist.md defines what to check for each OWASP category. Read the relevant section before judging a category you have not verified in this session.

Ground rules, and why

• Read-only by default. Never modify code, run migrations, delete data, or send attack payloads in passive mode. The scan script only reads.
• Secrets stay secret. If you find a live key, show the file and the variable name, never the value. Redact to sk-live-****1234. Tell the user to rotate it, not to paste it in chat.
• Measure, don't guess. Never claim a vulnerability without evidence: file:line plus the data flow, or an observed HTTP response. "Parece vulnerável" is not a finding.
• Staging over prod. Any live HTTP check goes to staging first. Against prod, only safe GET/HEAD/OPTIONS with no side effects.
• No new tooling without asking. Use the project's own stack, curl, and the bundled script. No installing Kali tools, no new npm packages unless the user agrees.
• Respect a denial. If a file or command is blocked by permissions, show the manual check instead of working around it.

Workflow

1. Scope

Ask in one message when the answers are not obvious:

1. Target: repo path and/or staging URL? What is out of scope?
2. Stack: framework, auth method (session/JWT/OAuth), where secrets live?
3. Mode: passive audit (default) or active against own staging?

Save the answers to pentest/<slug>/scope.md. Keep the run in pentest/<slug>/ at the project root (or a temp dir if the repo must not be touched):

pentest/<slug>/
├── scope.md
├── scan.txt
├── findings.md
└── report.md

2. Baseline scan

Run the read-only scan from this skill's directory:

bash <skill-dir>/scripts/scan.sh <project-root> [--url https://staging.example.com]

It reports: exposed secret patterns, .env and key files, dependency CVEs via the project's own audit commands, auth/session config smells, and — only when --url is given — response headers, cookie flags, CORS and TLS basics. Save the output to pentest/<slug>/scan.txt.

The script never sends payloads and never writes to the project.

3. Manual review

The script finds the cheap signals. You find the logic bugs. Cover at minimum, guided by references/checklist.md:

• Access control: every route/handler — who can call it, what object does it act on, is ownership checked (IDOR/BOLA)?
• Auth/session: password hashing, JWT validation (alg, exp, storage), OAuth redirect allowlist, logout, password reset tokens.
• Input/injection: where user input reaches SQL, ORM raw, shell, template, redirect, or file path. Trace the flow, don't grep keywords.
• Secrets/config: env handling, committed .env, CI logs, error messages leaking stack or keys.
• APIs: mass assignment, pagination without auth, webhook signature verification, CORS and rate-limit.

For each suspicion, confirm by reading the code path end to end before recording it.

4. Passive HTTP observation (only with --url)

curl -sI "<url>" ; curl -s -D - "<url>" -o /dev/null

Check HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Set-Cookie flags (Secure, HttpOnly, SameSite), CORS (Access-Control-Allow-Origin: * with credentials is a finding), and server version banners. One request per endpoint; no fuzzing, no parameter tampering in passive mode.

5. Score and report

Score with references/report.md (Critical/High/Medium/Low + likelihood × impact in one line each). Write report.md and show it in the conversation. If you cannot write files, put the full report in your reply.

# Pentest: <target>
 
**Scope:** repo · url · mode (passive) · date
**Stack:** <framework, auth, hosting>
**Scan:** N signals → V confirmed findings (C critical, H high, M medium, L low)
 
## Findings
### 1. <title> — <severity>
- **Where:** file:line / endpoint + method
- **Evidence:** redacted snippet or observed header
- **Impact:** what an attacker gains, in one line
- **Fix:** concrete change (config, code shape, snippet)
- **OWASP:** A0X:2021 – <name>
 
## Also checked (no issue)
| Area | Result |
 
## Next steps
- Rotate exposed secrets first, then fix Critical/High in order
- Re-run scan.sh after fixes; active testing only on staging with approval

Order findings by severity, then by exploitability. A finding without evidence goes to "Also checked", not to Findings.

6. Fixes (only if asked)

Fix in severity order, one change per finding, re-running the project's checks after each. Never commit exposed secrets to "fix" them — rotate outside git, purge history separately. Offer a follow-up scan as the verification step.

Pitfalls

• Keyword grep is not an audit. eval(, innerHTML, raw() appear in safe code too. Trace the data flow from request to sink.
• Severity inflation. A missing header alone is Medium at most. Without an impact path it is not Critical.
• Auth is logic, not headers. The worst bugs are missing ownership checks, not missing X-Frame-Options. Read the handlers.
• Do not "verify" by exploiting. Confirm by code path or by a single safe observation. Proof-of-concept payloads belong to active mode on staging, with explicit approval.
• Report what you did not check. No staging URL, no mobile app, no infra review — say so under "Also checked".