23andMe Bug Bounty

Welcome, Security Research Community!

23andMe recognizes the importance of working with skilled security researchers to identify and address vulnerabilities in our technology. We encourage responsible disclosure through our Bug Bounty Program and are excited to collaborate with you to enhance our security.

Scope

Testing is authorized only for targets explicitly listed as In-Scope. Any domain/property not listed is considered Out-of-Scope, including subdomains. If you discover a vulnerability outside the defined scope, contact [email protected] before submitting your findings. Failure to submit reports through our designated bug bounty route may result in a non-eligible report.

When Testing:

• Use your HackerOne email alias ([email protected]).
• Include the following header in all requests:

  X-HackerOne-Research: <YOUR-USERNAME>
  

• Automated tools: Limit requests to no more than 3 per second and avoid using vulnerability scanners.

Failure to follow these guidelines may result in disqualification from bounty rewards.

Program Rules

• Use your HackerOne email alias for account creation and testing.
• Add the X-HackerOne-Research header to all requests.
• Avoid using multiple IP addresses during testing.
• Refrain from public disclosure without 23andMe's written consent (even post-fix).
• Only test accounts you own or have explicit permission to interact with.
• Stop testing immediately if you encounter sensitive data and report it to us.
• Provide detailed, reproducible reports. Lack of detail may disqualify the submission.
• Submit one vulnerability per report unless chaining vulnerabilities to demonstrate impact.
• Social engineering (e.g., phishing) is prohibited.
• Avoid privacy violations, data destruction, or service disruption.
• Valid submissions must demonstrate a tangible security risk.
• Program terms may change at anytime. Participating means you agree to be bound by the new terms.
• For submissions involving Leaked Credentials:
  • Do NOT attempt to validate.
  • Attempting to sign in, change data, or test MFA with leaked credentials is forbidden.
  • Submit evidence only.
  • Attach the data dump.
  • Add the exact link or source of the leak. (Required)
  • No further testing—just share the data. For transparency, end-user credentials alone are usually out of scope unless a program-responsible leak source can be identified.

Focus Areas

Submissions addressing the following vulnerabilities are highly valued:

• Sensitive Data Exposure
• Remote Code Execution (RCE)
• Authentication Bypass
• Broken Access Control
• SQL Injection (or equivalent)
• Server-Side Request Forgery (SSRF)
• Malicious File Uploads
• XML External Entities (XXE)
• Cross-Site Scripting (XSS)
• Exfiltration of AWS credentials
• Misconfigured cloud infrastructure leading to data leakage

Submission Format

Reports that fail to follow this structure will likely be closed as informative. Clear writing and strong evidence matter more than length.

Title

A short, specific title naming the affected component and the issue.

Examples: "Multi-Compare Server-Side Limit Not Enforced", "IDOR in /profile/{id}/exports Allows Cross-Account Data Access"

Overview of the Vulnerability

A concise summary (2–4 sentences) covering:

• The affected feature or endpoint
• The expected behavior
• The actual (vulnerable) behavior
• Why it matters

Then provide a technical description in clear, factual prose:

• What the feature is designed to do
• What controls are documented or expected to be in place
• What your testing revealed about how those controls actually behave
• Specific observations from your requests — be precise with parameter names, HTTP methods, endpoint paths, and response details

When you ran multiple test cases, enumerate them so the reviewer can follow your reasoning:

• A request containing [input A] returned [observed result].
• A request containing [input B] returned [observed result].
• A request combining [A + B] returned [observed result].
• Reordering / duplicating / removing values resulted in [observed behavior].

Close with a one-sentence conclusion stating where the gap exists. For example: "This demonstrates that the five-profile limit is enforced exclusively at the UI layer and is not validated by the backend service."

Business Impact

State the impact in 1–3 sentences. Cover:

• What an attacker can actually achieve with this issue
• What mitigating controls remain in place (authorization, rate limiting, eligibility checks, etc.)
• A realistic assessment of severity

Be honest about limitations. If authorization checks still gate sensitive data, say so. Overstating impact slows triage and hurts credibility. Aim for accurate impact.

Demonstrated Impact (Not Theoretical)

Reports must show demonstrated impact, not hypothetical attack chains. Phrases like "an attacker could...", "this might allow...", or "if combined with..." — without a working proof-of-concept — will be closed as informational at best.

Anchor every impact claim to something you actually proved in your testing. Examples:

• Weak: "An attacker could potentially use this to exfiltrate user data." Strong: "Using test account A, I submitted [request] and retrieved [specific field] belonging to account B. Screenshot shows account B's email address in the response."

• Weak: "This reflected input might lead to XSS under the right conditions." Strong: "Payload <svg onload=alert(1)> in the q parameter executes in the rendered page. Screenshot of the triggered alert attached."

• Weak: "If chained with a future CSRF bypass, this could allow account takeover." Strong: "Demonstrated end-to-end with two test accounts: [steps]. Account B's session token is recovered at [location]."

If you can describe the attack but cannot demonstrate it, the report is incomplete. Either complete the chain end-to-end, or scope your impact claim to only what you proved. Incomplete demonstration will likely result in an informative report.

Steps to Reproduce

Numbered steps that a triager can follow without guessing. Each step should be specific and actionable.

1. Log in to [application] as a [user role / test account].
2. Navigate to [feature or URL].
3. Capture the request to [endpoint] using [Burp Suite / browser dev tools / curl].
4. Modify [specific parameter] from [value A] to [value B].
5. Replay the request.
6. Observe [expected behavior] vs. [actual behavior].

Include the raw HTTP request and response when they materially help explain the issue. Redact session tokens, cookies, and any data that doesn't belong to your test accounts.

Evidence

Screenshots (preferred):

• Annotated screenshots are the fastest way for triage to confirm an issue. Highlight the modified parameter, the relevant response field, or the UI state that contradicts the backend.
• At minimum, include: (1) the request showing your modification, (2) the response showing the vulnerable behavior, (3) any relevant UI state.

Video (helpful, especially for complex flows):

• Short screen recordings (under 2 minutes) are useful for multi-step issues, race conditions, or anything where timing matters.
• Video is a supplement to screenshots, not a replacement. Triagers can scan a screenshot in seconds; video requires playback.

Raw artifacts:

• Full HTTP request/response pairs, payloads, or proof-of-concept scripts where applicable.
• If your PoC needs setup, include a one-line description of what to run.

Remediation

State the fix in 1–3 sentences. Focus on:

• What validation or control is missing
• Where it should be enforced (which layer — backend, gateway, frontend)
• What the expected behavior should look like after the fix

Example: "Ensure the server performs the same validation as the UI and enforce the limit at the backend layer."

Scope Confirmation

Before submitting, confirm that the affected asset and the vulnerability class are in scope for this program. Review the In-Scope assets above and explicitly state in your report:

• The affected asset and where it appears in scope.
• Whether the vulnerability class is in scope, out of scope, or not explicitly addressed.
• If the issue touches an asset that is out of scope, do not submit. Contact [email protected] instead, as noted in the Scope section.

Reports targeting out-of-scope assets or vulnerability classes will be closed as N/A and may affect your reputation on the program.

Pre-Submission Checklist

• Affected asset and vulnerability class are confirmed in scope per program policy
• Title names the component and the issue
• Overview explains what's expected vs. what actually happens
• Business impact is realistic — not inflated, not understated
• Every impact claim is backed by a demonstrated PoC, not speculation
• Steps to reproduce work from a clean state
• At least one annotated screenshot of the request and response
• Sensitive data (tokens, PII, other users' data) is redacted
• X-HackerOne-Research header was used during testing / HackerOne email alias was used for test accounts

Disclosure Policy

Follow HackerOne's disclosure guidelines. Unauthorized public disclosure may result in disqualification from the program.

Happy Hunting!

We appreciate your contributions and look forward to collaborating with you to keep 23andMe secure.