The Best Claude Code Setup for Bug Bounty Hunting

target/
├── javascript/
├── requests/
├── urls.txt
├── endpoints.txt
└── notes/

claude mcp add burp --transport sse http://127.0.0.1:9876

  List the requests in my Burp proxy history, showing method, URL, and status code for each. Then do all of this in order:
  1) Summarize what this application is and its main features.
  2) Filter history to only ginandjuice.shop requests and highlight the most interesting ones (login, search, cart, checkout, APIs).
  3) List all API endpoints in a table with method, path, and parameters.
  4) Scan history for sensitive data — passwords, tokens, API keys, emails, personal info.
  5) Give me a final summary of what this app does and which endpoints are worth testing.

Analyze my Burp proxy history for ginandjuice.shop and identify the attack surface. In order:
  1) Find all requests with search or q parameters — injection candidates.
  2) Find all requests with numeric ID parameters (like id=1, /api/xxx/1, order numbers) — IDOR candidates.
  3) Find admin, profile, user, account, upload, and API endpoints.
  4) Find any JavaScript files in history and fetch the interesting ones, looking for hardcoded secrets, API paths, or clues.
  5) Output a clean prioritized list: the top 6 endpoints to test for bugs, grouped by bug type (SQLi, XSS, IDOR, auth).

Using the endpoints from the attack surface list, test ginandjuice.shop for vulnerabilities, one bug class at a time. Do them in this order and report a one-line result
  after each test:
  1) SQL injection — test the search endpoint with a single quote, OR  and UNION SELECT payloads.
  2) Reflected XSS — inject <script>alert(1)</script> into search and product parameters, check if it's reflected unencoded.
  3) IDOR — take order/profile requests and swap the ID for neighboring numbers (1, 2, 3); compare response lengths to confirm access to other users' data.
  4) Weak/default credentials — test login with common combos like admin/admin, admin@ginandjuice.shop:admin123, and note the exact error messages (user enumeration).
  5) User enumeration — compare login responses for a fake email vs an existing email.
  6) Rate limiting — send the login request 10 times fast; is there any lockout or rate limit?
  7) Broken access control — try hitting admin-only API endpoints (like /api/Users or /api/Products) unauthenticated.
  8) Business logic — try common coupon codes like GIN or JUICE and check if the discount can be reused.
  At the end, list every confirmed or suspected finding with severity, the endpoint, and which request proved it.

Write a professional pentest-style summary report of everything we found on ginandjuice.shop. For each finding include: vulnerability name, severity
(Critical/High/Medium/Low), affected endpoint, how it was exploited, and the proof (request + response). End with a prioritized fix list, most critical first. Also save
 the interesting requests to Burp Organizer for evidence.

ROLE
  You are a senior bug bounty hunter running a structured engagement against a live demo e-commerce target. You work methodically, you validate everything with real PoCs,
  and you never inflate severity. Every phase below builds on the previous one — do not skip ahead.

  SCOPE & RULES
  - Target: https://ginandjuice.shop/ only. Ignore every other host in Burp history.
  - Primary toolkit: Burp MCP (proxy history, regex filtering, Repeater, Collaborator, encoding). Direct HTTP calls only as a fallback.
  - Time-box each attempt: two clean exploitation tries per bug class, then move on. Dead ends are normal — log the negative result and continue.
  - Evidence-first: no finding enters the report without a reproducible request/response pair.

  PHASE 1 — PRE-ENGAGEMENT INTEL & SURFACE MODELING
  1. Build the operational picture from proxy history: inventory every host, page, endpoint, and API route; note methods and parameters.
  2. Fingerprint the stack: server headers, framework signatures, cookies (JWT? session cookie flags?), JS libraries, CDN/WAF presence.
  3. Mine the client side: fetch the JavaScript bundles in history and extract API paths, hardcoded secrets, and app logic clues (this is where hidden endpoints live).
  4. Map the auth model: login flow, token lifecycle, password reset behavior, registration, role structure, and any session-related headers.
  5. Regex-scan history for high-value signals: id=, search/q, admin|user|profile|upload paths, token/secret patterns, and sensitive data leakage.
  6. Produce an attack surface model: a scored list of endpoints with the bug classes most likely to succeed on each. No findings yet — this is intel only.

  PHASE 2 — ATTACK HYPOTHESES & PRIORITIZATION
  - Rank the attack surface by (impact × likelihood) ÷ effort. E-commerce priority: business logic and access control before generic injection.
  - Write 5-8 concrete attack hypotheses, e.g.: "the coupon endpoint accepts replay of a consumed code", "order IDs are sequential and unauthenticated reads leak customer
  data", "the search endpoint reflects input into the page without encoding".
  - State your expected evidence for each hypothesis before testing — a clean test needs a falsifiable claim.

  PHASE 3 — EXPLOITATION (in this order)
  1. Business logic: cart/price manipulation (negative quantities, tampered price fields, currency swaps), coupon logic (reuse, self-referral, rate), checkout state
  manipulation (skipping steps, reordering the flow).
  2. IDOR / broken object-level access: enumerate neighboring IDs on orders, profiles, and API objects; verify with response-content comparison, not just status codes.
  3. Authentication & session: default/weak creds, user enumeration, missing rate limiting, session fixation/invalidation gaps, token weaknesses.
  4. Access control: unauthenticated calls to user/admin APIs, privilege escalation via role or flag tampering, forced browsing.
  5. Injection: SQLi (classic, UNION, and blind via timing/boolean) on search and parameters; XSS (reflected in search, stored in reviews/profile fields, DOM sinks in
  JS); SSTI and command injection on file/export/convert features.
  6. Out-of-band: inject Collaborator payloads into any URL/fetch/image/import parameters for blind SSRF and XXE; poll for DNS/HTTP interactions.
  7. File upload & misc: extension/filter bypasses, content-type spoofing, same-origin serving, plus info disclosure (source maps, debug endpoints, backup files, verbose
  errors).

  PHASE 4 — CHAINING & IMPACT AMPLIFICATION (the part that makes findings severe)
  - For every confirmed primitive, map what it unlocks: can an IDOR pivot into account takeover? Can stored XSS capture an admin session? Can the coupon bug chain with
  registration into unlimited free orders? Can a leaked API key from JS escalate to admin API access?
  - Follow each chain to its maximum impact and document the full kill chain — a chain of two Mediums often reports as High/Critical.
  - Sweep for variant coverage: same bug class on other endpoints/parameters — one pattern, many surfaces.

  PHASE 5 — VALIDATION GATE (before anything enters the report)
  - Replay every finding with a clean, minimal request in Repeater; it must reproduce deterministically, twice.
  - Prove impact in the response: leaked data, executed code, state change, privileged action — no theoretical impact statements.
  - Kill any finding you can't stand behind. A report with 3 confirmed issues beats 12 speculative ones.
  - Store all PoC requests in Burp Organizer for the evidence appendix.

  PHASE 6 — PROFESSIONAL REPORT (triager-ready)
  Structure the final output exactly like a production submission:
  1. Executive summary — 3-4 lines: what the app is, what you found, overall risk posture.
  2. Findings — one entry per confirmed issue: Title / Severity (CVSS 3.1 vector + score) / Affected endpoint / Vulnerability class / Steps to reproduce (numbered,
  copy-pasteable) / Evidence (request + response excerpts) / Business impact (what an attacker actually gains) / Remediation (specific fix, not generic advice).
  3. Chained findings — for each chain, the component bugs and the escalation path.
  4. Summary table — all findings ranked by severity with a one-line fix each.
  5. Appendix — the Organizer request IDs as raw evidence.
  If the engagement produced no confirmed vulnerabilities, say exactly that, and close with the top 3 residual risks you observed with recommended hardening — a clean
  report is a credible report.

POST /api/v1/auth/signup HTTP/2
Host: demo.local
Cookie: session=eyJhbGciOiJIUzI1NiJ9.demo.session
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/139.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.9
Content-Type: application/json
Origin: https://demo.local
Referer: https://demo.local/register
X-CSRF-Token: demo-csrf-token
X-Forwarded-For: 127.0.0.1
Connection: keep-alive

{
  "username": "john.doe",
  "email": "john@example.com",
  "password": "Password123!",
  "confirmPassword": "Password123!",
  "role": "user",
  "inviteCode": "",
  "referrer": "newsletter"
}
Identify:
1. All user-controlled inputs and parameters.
2. Authentication and authorization mechanisms.
3. Interesting IDs and object references.
4. Potential IDOR/BOLA candidates.
5. Injection points.
6. Business-logic parameters.
7. Security-relevant headers and cookies.
8. Any unusual behavior that deserves further testing.

Rank each issue by severity. For each interesting point, explain why it is worth investigating and suggest manual testing steps.
Do not assume a vulnerability exists.
Separate observations from hypotheses.

Analyze this JavaScript file from a bug bounty perspective.

Extract and categorize:
1. API endpoints and URL paths.
2. HTTP methods.
3. Parameters and parameter names.
4. Authentication and authorization logic.
5. Hardcoded secrets, tokens, or API keys.
6. Administrative or internal endpoints.
7. Upload and download functionality.
8. Debug or development endpoints.
9. Hidden functionality and feature flags.
10. Interesting DOM sources and sinks.
11. Third-party integrations.

For every interesting discovery, explain why it deserves further investigation.
Do not report something as a vulnerability unless there is enough evidence to support it.

Analyze this JavaScript file for security-relevant information:
<JS_URL>
Look for:
1. API endpoints and hidden routes
2. Interesting parameters
3. Authentication or authorization logic
4. Hardcoded secrets or sensitive information
5. Internal or administrative functionality
6. Debug or development endpoints
7. Client-side security issues
8. Anything else that could be useful for authorized security testing
For each finding, explain why it is interesting and provide the relevant code or URL as evidence.

Analyze every JavaScript file in this directory.
Build a consolidated attack-surface map containing:

1. API endpoints
2. HTTP methods
3. Parameters
4. Authentication functionality
5. Authorization logic
6. Administrative functionality
7. Upload/download features
8. WebSocket endpoints
9. Third-party integrations
10. Hardcoded secrets or credentials
11. Interesting client-side sinks
12. Hidden or undocumented functionality

Deduplicate identical endpoints and group related functionality together.

For each discovery, include relevant details and explain why it is interesting from a security-testing perspective.

At the end, rank the top 10 discoveries that deserve manual security testing and explain why each one is interesting.

Do not assume a vulnerability exists. Clearly separate observed functionality from security hypotheses.

Analyze this request for a possible IDOR/BOLA vulnerability.

Explain:
1. Why this request could be interesting.
2. Which parameter controls the object being accessed.
3. What needs to change to test the authorization boundary.
4. What response differences would confirm the issue.
5. How I should manually validate the finding.

Do not assume the vulnerability exists.
Clearly distinguish observations from hypotheses.
Explain what evidence would be required to confirm the issue.

Review this source code from a security perspective.

Identify:
1. Authentication weaknesses.
2. Authorization and access-control issues.
3. Input validation problems.
4. Injection risks.
5. Sensitive information exposure.
6. Insecure file handling.
7. Session-management issues.
8. Business-logic flaws.

For every confirmed or evidence-supported issue:
- Explain the root cause.
- Point to the relevant code.
- Explain the security impact.
- Suggest a secure fix.
- Explain how the issue could be manually validated in an authorized environment.

Do not report theoretical issues without explaining the evidence.
Clearly distinguish confirmed issues, security-relevant observations, and hypotheses.
Prioritize findings by severity and practical exploitability.

Based on the provided HTTP requests, JavaScript analysis, recon results, and testing notes, create a professional bug bounty report.

For each confirmed finding, include:
- Title
- Severity
- Affected endpoint
- Vulnerability class
- Steps to reproduce
- Evidence
- Security impact
- Remediation

Structure the report clearly and professionally.

Separate:
1. Confirmed vulnerabilities
2. Security-relevant observations
3. Potential issues requiring further validation

Do not include speculative findings as confirmed vulnerabilities.
Only classify an issue as a confirmed vulnerability when the provided evidence demonstrates an actual security impact.
Clearly distinguish observed behavior from security conclusions.
Rank confirmed findings by severity and practical impact.

project/
├── recon/
│   ├── subdomains.txt
│   ├── alive.txt
│   └── urls.txt
│
├── requests/
│   ├── login.txt
│   ├── profile.txt
│   └── api.txt
│
├── javascript/
│   ├── app.js
│   ├── dashboard.js
│   └── auth.js
│
└── source/
    └── application-code/

You are assisting with an authorized security assessment.
Analyze the files in this project and correlate the information across recon, HTTP requests, JavaScript, and source code.

Build:

1. An attack-surface map.
2. An API inventory.
3. An authentication and authorization map.
4. A list of interesting parameters and object IDs.
5. Hidden functionality discovered in JavaScript or source code.
6. Potential vulnerability hypotheses.
7. A prioritized manual testing plan.
8. Confirmed findings supported by the provided evidence.
9. A professional security report.

Do not treat suspicious patterns as confirmed vulnerabilities.

For every finding, clearly explain the evidence that supports it and what additional validation is required.

Create a Claude Code Skill for finding and validating open redirect vulnerabilities.

Use the methodology below as the source material:

[PASTE YOUR OPEN REDIRECT METHODOLOGY HERE]

Convert this methodology into a complete reusable Skill. Include:
- Skill name and description
- Detection methodology
- Testing workflow
- Common parameters to test
- Payloads and bypass techniques
- Validation steps
- Useful CLI tools
- Expected findings and false positives
- Reporting workflow

Organize everything into a practical workflow Claude can follow during an authorized bug bounty assessment.

Do not invent techniques that are not supported by the methodology. Keep the Skill focused on open redirect testing.

Create a Claude Code Skill for XSS hunting based on the methodology below:

[PASTE YOUR XSS RESEARCH OR NOTES HERE]

Turn this into a structured Skill that Claude can use during authorized security testing.

Include:
- Reconnaissance and input discovery
- Reflection detection
- Parameter and endpoint testing
- Context identification
- Payload selection
- Filter and encoding analysis
- Safe validation techniques
- Useful tools and commands
- False-positive handling
- Finding documentation and reporting

Preserve the methodology from my research and organize it into a repeatable workflow.

I have developed the following bug hunting methodology:

[PASTE YOUR COMPLETE METHODOLOGY HERE]

Convert this into a production-ready Claude Code Skill.

First understand the methodology and break it into logical phases.

Then create:
1. Skill name
2. Description
3. SKILL.md
4. Required tools
5. Testing workflow
6. Payloads or test cases
7. Helper scripts if required
8. Validation methodology
9. Reporting format
10. Any supporting resource files

Keep the workflow faithful to my original methodology.

The Skill will be used only for authorized security testing and bug bounty programs.

My locally installed security tools are available at:

[PASTE YOUR TOOL PATHS HERE]

Use these existing binaries when appropriate instead of attempting to install alternative versions.