evidence-hygiene

name	evidence-hygiene
description	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.
sources	field_recon, bug_bounty_reports
report_count	8

EVIDENCE HYGIENE — PoC Capture & Redaction Discipline

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
• Analytics cookies (ajs_anonymous_id, _ga)
• Trace correlation IDs (x-datadog-trace-id, x-request-id)
• 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 annotation tools 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
• The endpoint URL and request method
• The trace ID

3.3 Worked example — IDOR PoC body

Bad (leaks victim's full PII):

{"data":{"contact":{"first_name":"Nadene","last_name":"Afton","email":"[e-mail]","phone":"[phone]"}}}

Good (proves the bug, masks the PII):

{"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"
}

Usage:

sanitize_har /path/to/exported.har
# Output: /path/to/exported.sanitized.har

4.3 Verify before attaching

# 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)

1. 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
2. Or: temporarily delete the Cookie header text from the Repeater pane (it doesn't affect the original captured request) before screenshotting, then restore
3. Capture only the response panel (right side) showing the JSON / HTML response that demonstrates the bug

5.2 Intruder Results table (rate-limit / brute-force demos)

The Results window is the strongest evidence for rate-limit findings. To capture cleanly:

1. 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
2. Screenshot only the columns: Request#, Payload, Status code, Response received, Length
3. 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 code
  body: 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:

fetch('/api/endpoint', { /* ... */ })
  .then(r => r.json())
  .then(j => {
    console.log("RESPONSE SHAPE:", Object.keys(j.data || {}));
    console.log("CRITICAL FIELD:", j.data?.victim_id, j.data?.email);
    // (Don't dump the full j — your screenshot becomes unreadable)
  })

6.4 Allow-pasting reminder

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:

1. Pre-state verification — verify_password("current") → true. Proves you knew the starting state.
2. The bug itself — update_password(...) succeeds without step-up. THE most important screenshot.
3. Post-state verification (negative) — verify_password("old") → false. Proves the change took effect.
4. Post-state verification (positive) — verify_password("new") → true. Proves the new credential is active.
5. Out-of-band side effects — inbox screenshot showing whether a notification email arrived. Proves whether passive defense exists.

7.2 Filename conventions

Numbered, descriptive, hyphen-separated:

{finding-#}-step{step-#}-{description}.png

Examples:
04-step1-verify-true-before.png
04-step2-update-password-no-stepup.png
04-step3-verify-false-after.png
04-step4-verify-true-new-pw.png
04-step5-inbox-notification-check.png

In the report body, reference each by filename:

- **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 (e.g. "ecommerce-wine.com has PHPInfo exposed")
• 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 sector labels: e-commerce site instead of ecommerce-wine.com
• Replace counts with ranges: several users instead of 11 users
• Describe patterns without PII: CORS credential reflection on WP REST API not CORS on realestate-platform.com
• 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:

A README with ecommerce-wine.com — PHPInfo + open reg → RCE reveals to EVERYONE that this specific company is vulnerable. The data belongs to the client/engagement, not to public showcases. Pattern-based descriptions teach without exposing.

---

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.

---

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

---

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.