/kosuke:web-pentest
/kosuke:web-pentest checks your project's own app for security holes. The agent reads the source first, then tries each suspected hole against the running Preview with one careful request. You get a report of real vulnerabilities, each with a severity, the file and line, a proof and a fix. It changes no code.
When to use it
Run it before a release, or after a change to sign-in, permissions, payments or file uploads.
- The agent proves findings against the session's Preview, so start it first. Without a running Preview, findings stay code-review-only. See Preview and sandboxes.
- The report arrives as the agent's reply in the chat.
Run it
Type /kosuke:web-pentest, or $kosuke:web-pentest in a Codex session.
| Argument | What it does | Default |
|---|---|---|
| Focus area or scope note | Where to start, such as one feature or one set of routes. The report still lists what it skipped. | The whole app |
/kosuke:web-pentest
/kosuke:web-pentest the billing API
/kosuke:web-pentest only the public share links
What it does
- It maps the app's entry points and every place user input reaches a query, a command, a file path, an outbound request or a page. It writes a short threat model.
- It checks the code for each category in the table below.
- It tries each finding against the Preview with one request. It signs in as whichever user the attack needs, such as a second user for an access test, and shows the attack working.
- When it cannot reproduce a finding, it marks the finding code-review-only and gives the exploit path as the proof.
- It drops any finding without a source location, a proof, real impact, or a place in scope.
- It posts the report.
| Category | What it looks for |
|---|---|
| Injection | SQL, shell commands, templates or file paths built from user input |
| Broken access control and IDOR | Reading or changing another user's record by changing an ID |
| Authentication and session | Weak sessions, token checks, password reset and cookie settings |
| SSRF | The server fetching a URL an attacker chooses |
| XSS and CSRF | User input rendered as HTML, and actions a forged request can trigger |
| Secrets and misconfiguration | Hardcoded secrets, open CORS, missing security headers, leaky errors |
| Business logic | Price tampering, skipped steps, races on credits or limits |
| Deserialization and file upload | Untrusted data unpacked as objects, uploads with no type or path limits |
What you get
One report in the reply. It has a summary with counts by severity, the threat model, the findings from most to least severe, and the categories it covered and did not cover. It says which findings it proved against the Preview and which are code-review-only.
| Field | What it holds |
|---|---|
| Title | What the hole is |
| Severity | Critical, High, Medium, Low or Info |
| CWE | The standard ID for this kind of weakness |
| Location | The file and line |
| Description | What the flaw is and how it works |
| Proof | The request and response, or the exploit path, with secrets hidden |
| Impact | What an attacker gains |
| Remediation | The fix, pointing at the code |
Severity weighs impact against how easy the attack is. A problem with no way to exploit it is Info.
To fix a finding, ask the agent in a message. The fix is a separate task, because this skill only audits.
Limits
- It changes no code, migrations or configuration.
- It runs nothing destructive or noisy. There are no data-deleting payloads, no denial of service, no password guessing and no mass fuzzing.
- It touches only your app's own source and Preview. Other hosts, tenants, users' data and outside services stay out of scope.
- It never prints a full secret. It names the file and line instead.