Evidence-capture and PoC-redaction discipline for bug-bounty submissions: cookie redaction protocol (which fields to mask, Preview annotation / Burp panel hiding / DevTools workflow), PII black-bar discipline (what to mask in other-user data — names, emails, phones, faces — vs what is safe to leave — usernames, trace IDs, request bodies), HAR file sanitization (jq filters for Cookie/Set-Cookie/Authorization headers), Burp Repeater/Intruder screenshot hygiene (hide request body, show only Results table for rate-limit attacks), Chrome DevTools Console PoC patterns (credentials include so cookies are not echoed, labeled console.log), screenshot capture order, filename conventions, post-submission rotation hygiene. Use BEFORE any PoC screenshot, BEFORE attaching a HAR, or whenever preparing evidence with session cookies or other-user PII. Pairs with bugcrowd-reporting and report-writing.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Evidence-capture and PoC-redaction discipline for bug-bounty submissions: cookie redaction protocol (which fields to mask, Preview annotation / Burp panel hiding / DevTools workflow), PII black-bar discipline (what to mask in other-user data — names, emails, phones, faces — vs what is safe to leave — usernames, trace IDs, request bodies), HAR file sanitization (jq filters for Cookie/Set-Cookie/Authorization headers), Burp Repeater/Intruder screenshot hygiene (hide request body, show only Results table for rate-limit attacks), Chrome DevTools Console PoC patterns (credentials include so cookies are not echoed, labeled console.log), screenshot capture order, filename conventions, post-submission rotation hygiene. Use BEFORE any PoC screenshot, BEFORE attaching a HAR, or whenever preparing evidence with session cookies or other-user PII. Pairs with bugcrowd-reporting and report-writing.
Use this skill BEFORE capturing any screenshot, exporting any HAR, or attaching any evidence to a bug-bounty submission. It catches the most common evidence-hygiene mistakes that cause cookies to leak, PII to be shared without consent, or screenshots to be unsuitable for triage.
The core principle: Bug-bounty evidence is meant to convince a triager. Anything beyond that — live cookies, real-user PII, internal trace IDs that aren't useful — should not be in the evidence.
1. Two Categories of Sensitive Data
Every PoC artifact (screenshot, HAR, raw HTTP request, terminal transcript) potentially contains data that needs different treatment.
Category
Examples
Treatment
Your-account secrets
Session cookies, OAuth tokens, refresh tokens, API keys
Always redact. Even in private bug-bounty platform attachments. Your account, your session — protect it.
Other users' PII
Real names, emails, phone numbers, addresses, profile photos, account IDs
Redact unless explicitly demonstrating cross-account impact. Even then, mask faces and minimize the data you display.
Triager-useful metadata
Trace IDs (x-datadog-trace-id), request IDs, server timestamps, your test account UID/email, GraphQL operation names, response shapes
Leave visible — these help the triager correlate to logs and reproduce.
Test-account passwords (limited use)
Throwaway passwords on a test account (e.g., Testing@5678)
Acceptable in screenshots if you rotate immediately after submission so the value shown is dead. Don't leave real-use passwords in evidence.
2. Cookie Redaction Protocol
2.1 What must be masked
The session cookie value is the highest-value secret in any PoC. Mask:
The session cookie (authn, session, sid, __Secure-id, etc. — name varies per target)
csrf-token if it's bound to your session
Authorization headers (Bearer tokens, JWT)
Cookie request header values for any session-bearing cookie
Set-Cookie response header values for any session-bearing cookie
2.2 What's safe to leave visible
Cloudflare cookies (__cf_bm, _cfuvid) — these are bot-management, not session-bearing
Server / framework headers (Server: cloudflare, X-Frame-Options)
Your test account email/UID (per Bugcrowdninja alias section in bugcrowd-reporting)
2.3 Redaction methods (ranked by practicality)
Method A — Don't capture the cookies in the first place (preferred when possible)
For DevTools Console PoCs: use credentials: 'include' so the browser sends cookies automatically. Console output won't echo the cookie. Screenshot the Console output, never the Network tab Headers panel.
For Burp Repeater PoCs: drag the bottom request/response panel divider DOWN to hide the request body before screenshotting. Capture only the Results table for Intruder runs.
Method B — Black-bar in image editor (when capture inevitably includes cookies)
macOS: Open screenshot in Preview → Tools → Annotate → Rectangle → set fill color to black → drag rectangle over the cookie value → save
Windows: Use Snip & Sketch's annotationtools or any image editor (Paint.NET, etc.)
Burp itself: in Burp's Proxy → Match and Replace, you can pre-emptively redact cookie values to placeholder strings before screenshotting
Method C — Find/replace in raw text (for HAR files, terminal transcripts)
See §4 for the jq commands
2.4 Pre-screenshot checklist
Before clicking Capture:
[ ] Network tab Headers panel is collapsed or out of frame
[ ] Burp's Request panel is hidden behind the divider drag
[ ] No "Copy as cURL" output is visible on screen
[ ] DevTools Application → Storage → Cookies tab is closed
[ ] Browser URL bar doesn't show a session token in query string (rare but possible)
After capturing:
[ ] Open the screenshot at full resolution before saving
[ ] Search for the session cookie name substring in any visible text — if present, redact
[ ] Search for the literal first 6 chars of your cookie value — if present, redact
[ ] Compare to the previous PoC screenshot in the same engagement — same redaction discipline
3. PII Black-Bar Protocol
When a PoC necessarily exposes another user's data (e.g., demonstrating IDOR by showing the victim's email in an attacker-session response), redact the actual PII even in private attachments.
3.1 What to mask (other-user data)
First name, last name (full or partial)
Email address (mask the local part; can leave domain if non-identifying)
Phone number (mask the last 7 digits, optionally leave country code)
Physical address (mask everything below city)
Date of birth (mask the year, optionally the month)
Government IDs (SSN, passport — mask everything)
Profile photos / face images (black-bar the face entirely)
Account IDs that the user could correlate to public profiles
3.2 What to leave visible (proves the bug, not the user)
The fact that the field was returned (the JSON key name)
The shape / type of the field ("first_name": "<REDACTED>")
Your own (attacker session's) UID / email — this proves cross-account
{"data":{"contact":{"first_name":"<REDACTED — real first name>","last_name":"<REDACTED — real last name>","email":"<REDACTED>@example.com","phone":"<REDACTED>"}}}
In screenshot form, black-bar each value with a rectangle annotation labeled "REAL PII REDACTED" if there's space.
3.4 In the report body
Reference the redaction explicitly:
## Proof of Concept
The screenshot below demonstrates the IDOR. The attacker session (uid 12345678) successfully retrieves the victim's profile data (uid 99887766). **Real PII fields in the response are masked with black rectangles to limit unauthorized exposure of victim data, per responsible-disclosure hygiene.** The unredacted response is available privately on request.
This signals the triager that you're disciplined and gives them a clear path to the unredacted version if they need it for verification.
4. HAR File Sanitization
HAR (HTTP Archive) files are JSON dumps of network traffic with full request/response bodies and headers. They include cookies, auth tokens, and any PII that was in transit.
4.1 Generate the HAR
Chrome DevTools → Network tab → right-click anywhere in the request list → "Save all as HAR with content"
4.2 Sanitize before attaching
Use jq to strip sensitive headers. Save this as a shell function or one-liner you can re-use:
sanitize_har() {
local input="$1"local output="${1%.har}.sanitized.har"
jq '
.log.entries |= map(
(.request.headers |= map(
if .name | ascii_downcase | IN("cookie", "authorization", "x-csrf-token") then .value = "<REDACTED>" else . end
)) |
(.response.headers |= map(
if .name | ascii_downcase | IN("set-cookie") then .value = "<REDACTED>" else . end
)) |
(.request.cookies |= map(.value = "<REDACTED>")) |
(.response.cookies |= map(.value = "<REDACTED>"))
)
'"$input" > "$output"echo"Sanitized: $output"
}
# Check that no Cookie or Authorization values are leaking
grep -i 'authn\|"cookie"\|authorization' /path/to/exported.sanitized.har | head -20
If you see your real cookie value in the output, the sanitization missed something — fix the jq filter for that specific field name.
4.4 Remove other-user PII (if applicable)
If the HAR captured cross-account data (e.g., during an IDOR demo), additionally strip the response body fields that contain victim PII. Add to the jq filter:
(.response.content.text |= (
if . then
(fromjson? // .) | tostring | gsub("real.first.name.example"; "<REDACTED>")
else . end
))
Customize the gsub patterns to your specific captured data.
5. Burp Suite Screenshot Hygiene
5.1 Repeater (single request demo)
In the Repeater request panel, the Cookie header is on its own line — drag the panel divider DOWN to hide everything below the request line / target line
Or: temporarily delete the Cookie header text from the Repeater pane (it doesn't affect the original captured request) before screenshotting, then restore
Capture only the response panel (right side) showing the JSON / HTML response that demonstrates the bug
The Results window is the strongest evidence for rate-limit findings. To capture cleanly:
After the attack finishes, drag the horizontal divider between the Results table and the Request/Response panels DOWN, until only the Results table is visible
Screenshot only the columns: Request#, Payload, Status code, Response received, Length
Don't include the Request / Response sub-panels — they contain the cookie
5.3 Proxy HTTP history (capture demo)
Almost never the right screenshot — it shows entire request/response pairs with cookies. Use Repeater for demos instead.
5.4 Scanner findings (if applicable)
The Scanner tab's Issues panel is generally safe to screenshot — it shows finding summaries without the underlying request bodies. Click into a specific finding before screenshotting only if you've redacted its evidence first.
6. Chrome DevTools Console PoC Patterns
6.1 The clean-PoC pattern
fetch('/api/endpoint', {
method: 'POST',
headers: {'content-type': 'application/json'},
credentials: 'include', // sends cookies automatically — they won't appear in your codebody: JSON.stringify({ /* your payload */ })
}).then(r => r.json()).then(j =>console.log("LABEL:", JSON.stringify(j)))
Why this is clean:
credentials: 'include' means the browser sends cookies. Your code never references them. They never appear in screenshots.
console.log("LABEL:", ...) produces a labeled output line you can search for in the screenshot
JSON.stringify(j) formats the response on a single line — easier to crop tightly
6.2 Multi-step PoCs (clear console between calls)
For a 4-step PoC (verify before / change / verify after / revert), clear the console between calls so each screenshot only shows ONE call and ONE response:
Mac: Cmd+K
Windows / Linux: Ctrl+L
Take the screenshot immediately after the response prints — don't wait for unrelated framework warnings to appear.
6.3 Long responses (truncate for screenshot)
If the response body is too long for a clean screenshot, log a summary instead:
Chrome blocks paste into DevTools Console as anti-self-XSS protection. Type allow pasting (literal phrase) once at the start of each session. Do this BEFORE you take any "running PoC" screenshot — otherwise the warning text appears in the screenshot.
7. Screenshot Capture Order Discipline
7.1 The 5-step PoC pattern (for state-change findings)
For findings like "password change without step-up," the canonical 5-screenshot pattern is:
Pre-state verification — verify_password("current") → true. Proves you knew the starting state.
The bug itself — update_password(...) succeeds without step-up. THE most important screenshot.
Post-state verification (negative) — verify_password("old") → false. Proves the change took effect.
Post-state verification (positive) — verify_password("new") → true. Proves the new credential is active.
Out-of-band side effects — inbox screenshot showing whether a notification email arrived. Proves whether passive defense exists.
-**Screenshot 1 (`04-step1-verify-true-before.png`)** — verify_password returns true with the current password.
- **Screenshot 2 (`04-step2-update-password-no-stepup.png`)** — update_password returns User with no StepUpRequiredError. THIS IS THE BUG.
-**Screenshot 3 (`04-step3-verify-false-after.png`)** — verify_password with old password returns false.
- **Screenshot 4 (`04-step4-verify-true-new-pw.png`)** — verify_password with new password returns true.
-**Screenshot 5 (`04-step5-inbox-notification-check.png`)** — inbox showing whether out-of-band notification was sent.
7.3 Capture timing
Take all screenshots in one sitting, not across multiple sessions. Mid-session inconsistencies (different browser sizes, different cookie values) are confusing for the triager.
Don't reload pages between screenshots if avoidable. Reloads regenerate cookies and may invalidate prior captures.
Public-Facing Output Sanitization (OPSEC)
When publishing ANY output to public channels (GitHub README, blog posts, reports, shared dashboards):
Rules — NEVER include:
Company/domain names with specific vulnerability details.
Person names (employees, users, researchers)
Email addresses of real people
Internal IPs, hostnames, or AD domains
Raw credentials (even if expired)
Safe alternatives:
Replace company names with a sector or neutral target label.
Replace counts with ranges: several users instead of 11 users
Describe reusable patterns without engagement identifiers.
Use agnostic tables: | Critical | 8 | MySQL exposed, PHPInfo + exec | not naming specific targets
Checklist before public push:
[ ] Scanned for hardcoded domain names (grep -E '[a-z]+\\.(com|io|app)' *.md)
[ ] Scanned for email addresses (grep -E '[a-zA-Z.+-]+@[a-zA-Z-]+\\.[a-zA-Z.]+' *.md)
[ ] Scanned for internal IPs (grep -E '10\\.|172\\.1[6-9]\\.|192\\.168\\.' *.md)
[ ] Confirmed no person names in output
[ ] Confirmed vuln descriptions are pattern-based, not target-based
Real-world consequence:
Publishing a target name beside a vulnerability discloses engagement data.
Pattern-based descriptions preserve the reusable lesson without exposing the
target.
Post-submission hygiene
After clicking Submit on the bug-bounty platform:
8.1 Rotate the test account credentials
1. Log out of the target
2. Log back in (this rotates the session cookie — any cookie shown in your screenshots is now dead)
3. Change the password to a fresh value not used elsewhere (any password shown in your screenshots is now dead)
8.2 Save the unredacted artifacts privately
Keep your unredacted HARs / screenshots in a local folder accessible only to you. The triager may ask for the unredacted version during verification. Never share unredacted artifacts via email — use the platform's private attachment system on the existing submission thread.
8.3 Don't post about the finding publicly
Most platforms' confidentiality applies to BOTH unresolved and resolved issues. Don't tweet, blog, or discuss the finding in any forum until the program explicitly says you can.
8.4 Audit your local artifacts
Quarterly, sweep your ~/security-research/ and ~/Downloads/ for stale HARs / screenshots from old engagements. Either move them to a properly-encrypted archive or delete them. Bug-bounty engagement artifacts are sensitive — they accumulate fast and become a liability.
Pitfalls
Capturing cookies in screenshots — the #1 evidence-hygiene mistake. Always collapse the Network tab Headers panel, hide the Burp Request panel, and never screenshot "Copy as cURL" output.
Leaving victim PII unredacted — IDOR PoCs that show real names, emails, and phone numbers violate responsible disclosure. Black-bar all other-user PII even in private platform attachments.
HAR files with live cookies — exported HARs contain full cookie values unless sanitized with jq. Always run the sanitize_har function before attaching.
Console.log echoing cookies — DevTools Console PoCs must use credentials: 'include', never hardcode cookie values in fetch calls.
Forgetting "allow pasting" — Chrome blocks paste into Console by default. Type allow pasting before any PoC to prevent the warning text from appearing in screenshots.
Not clearing Console between steps — multi-step PoCs with overlapping console output confuse triagers. Clear Console (Cmd+K / Ctrl+L) between each call.
Screenshotting Proxy HTTP history — shows entire request/response with cookies. Use Repeater instead and hide the request panel.
Post-submission cookie not rotated — cookies visible in submitted screenshots are dead only after logout/login rotation. Rotate immediately after submission.
Inconsistent screenshot dimensions — different browser sizes across PoC steps look sloppy. Take all screenshots in one sitting with consistent window size.
Not saving unredacted originals — triagers may request the unredacted version. Keep originals in a local encrypted folder; never share via email.
Public output with real domains — any README/blog/report with "target.example.com — vuln detail" exposes the client. Use sector labels and pattern-based descriptions.
Stale artifacts accumulating — HARs and screenshots from old engagements pile up. Quarterly audit: archive or delete stale evidence files.
9. Pairing with Other Skills
For this question / task
Use this skill
"Should I report this finding at all?"
triage-validation
"What's the report body template?"
report-writing
"What VRT / severity / OOS rebuttal for Bugcrowd?"
bugcrowd-reporting
"How do I redact / sanitize this evidence?"
This skill (evidence-hygiene)
"How do I demonstrate the bug actually fires?"
security-arsenal
"Where are the recon probes for this asset class?"
offensive-osint
Verification
Run this self-test to confirm evidence-hygiene readiness:
HAR sanitizer syntax — verify the jq filter is syntactically valid:
grep -q "Rotate the test account credentials" SKILL.md && echo"PASS" || echo"FAIL"
All 5 tests verify the critical evidence-hygiene safeguards are present.
Notes on usage
This skill is meant to be loaded together with report-writing and (for Bugcrowd) bugcrowd-reporting when preparing a submission. It does NOT cover:
What to capture (that's triage-validation and report-writing's job — they tell you what evidence is required for the report to be accepted)
How to demonstrate exploitation (that's security-arsenal's job — payloads to send)
Where to find the assets (that's offensive-osint's job — recon)
This skill covers ONLY the redaction / sanitization / hygiene layer that sits between "I have evidence" and "I'm attaching it to the platform."
Related Skills & Chains
report-writing — When evidence is redacted and ready for the report body. Workflow primitive: after redaction passes the pre-screenshot checklist, hand off to report-writing for the platform-specific report template (H1 / Bugcrowd / Intigriti / Immunefi).
bugcrowd-reporting — When the redacted evidence is destined for Bugcrowd specifically. Workflow primitive: redacted screenshots + sanitized HARs become attachments referenced in bugcrowd-reporting's VRT-mapped submission body.
triage-validation — When deciding which evidence is required at all. Workflow primitive: triage-validation says "you need a 5-screenshot PoC for password-change-without-step-up"; this skill says "here's how to capture and redact those 5 screenshots cleanly."
security-arsenal — When the payload that produced the evidence is being documented. Workflow primitive: the payload (from security-arsenal) goes in the report verbatim; its output / response (handled by this skill) gets cookie / PII redacted before screenshotting.
bb-methodology — When Phase 5 (Validate & Report) needs evidence captured. Workflow primitive: Phase 5's evidence-capture step routes through this skill before the report is drafted.
