Authorized bug bounty testing across authentication flows, object-level authorization, client-side disclosure, and e-commerce logic on a platform handling sensitive genetic data.

This writeup documents a focused security assessment of 23andMe's web platform conducted through their public bug bounty program. The assessment targeted authentication flows, object-level authorization, client-side information disclosure, and e-commerce logic across all four primary in-scope assets.

23andMe handles particularly sensitive data — genetic profiles, health reports, and ancestry information — making authorization integrity the highest priority test area.

Target: 23andMe Bug Bounty Program (HackerOne — Public) Date: April 23, 2026 Auth: Fully authorized — HackerOne public program Scope: api.23andme.com · auth.23andme.com · store.23andme.com · you.23andme.com Tools: Burp Suite Community, Firefox + FoxyProxy

1. Testing Environment

Burp Suite Community was configured as an intercepting proxy, with Firefox routing all traffic through it via FoxyProxy. The Burp CA certificate was installed in Firefox for full HTTPS decryption. Two test accounts were created — one using the HackerOne alias email, one using a separate Gmail account — for cross-account authorization testing.

2. Application Mapping and Reconnaissance

With Burp's HTTP history running passively, I browsed all four in-scope assets to establish a baseline of request patterns. The first significant observation was the profile ID architecture: every authenticated request embeds a 16-character hexadecimal profile ID in the URL path, appearing simultaneously in the URL, the current-profile-id cookie, and the ajs_user_id analytics cookie.

This triple-presence pattern immediately raises the question of which source the server actually trusts for authorization — the URL, the cookie, or the session. Answering that became the primary focus of Phase 3.

Technology Stack

• Frontend: React SPA
• Backend: Django (Python) — confirmed via session cookie format and CSRF token structure
• CDN/WAF: Cloudflare on all subdomains
• Payment processing: Braintree
• Infrastructure: AWS

Finding: Feature Flag System Exposed in Page JavaScript

The application embeds its complete internal feature flag registry in every page response. This includes hundreds of named internal features — EHR integrations, clinical service connections, AI assistant endpoints, and internal naming conventions — all publicly visible in the page source without authentication.

While not directly exploitable, this exposes 23andMe's internal feature architecture. An attacker reading medicine_cabinet_ehr_v1: true and clinic_consumer_v1: true knows exactly where to probe for clinical data endpoints.

3. Authentication Testing — auth.23andme.com

Endpoint Reconnaissance

Direct path testing against auth.23andme.com through Burp Repeater revealed that sensitive administrative paths exist but are protected by Cloudflare's WAF. The /admin/ path triggers a JavaScript challenge rather than a flat 403 — indicating a managed challenge rule, stronger than a basic block.

Password Reset Flow — Four Attack Vectors

The password reset mechanism was tested across four distinct attack vectors: token in response, host header injection, token entropy, and deprecated security headers.

✅ Token in Response — SecureThe API returns only the submitted email address. No reset token is included in the response body.

✅ Host Header Injection — Not VulnerableAdding X-Forwarded-Host: attacker.com had no effect. Reset email arrived pointing to auth.23andme.com.

Token entropy analysis: The reset token is double base64-encoded random binary data with no predictable components — no timestamps, user IDs, or sequential elements. Not guessable or forgeable.

4. Object-Level Authorization — you.23andme.com

BOLA is the highest-priority vulnerability class for an application storing per-user genetic data. I tested whether the profile ID in the URL path is trusted for authorization, or whether the server enforces identity through the session token alone.

Phase 1 — Single Account Profile ID Manipulation

Using Account A, I modified the profile ID in URL paths while keeping the original session unchanged and sent requests through Burp Repeater.

The server consistently reset current-profile-id to the session's legitimate profile ID — overriding the client-supplied value. This confirms the server derives identity from the session, not from client-supplied object references in the URL.

Phase 2 — Two-Account Cross-Access Test

The definitive BOLA test: using Account B's session to request Account A's profile endpoints by supplying Account A's profile ID in the URL.

✅ BOLA — Not VulnerableThe server ignores client-supplied profile IDs entirely and serves data based on the authenticated session. Correct implementation for a platform handling genetic and health data.

5. E-Commerce Testing — store.23andme.com

The store checkout flow was analyzed for price manipulation, mass assignment, and token exposure vulnerabilities.

Mapbox Token Exposure

A live Mapbox API token is returned in every checkout context response regardless of authentication state. Mapbox tokens scoped with write permissions can be used to make API calls billed to the token owner. The actual risk depends on the token's permission scope.

Cart Item BOLA Test

Cart items use base64-encoded sequential integers as identifiers (Mjk1Nzg0NTY= → 29578456). Testing adjacent IDs with a different session returned 404 across all attempts — cart items are correctly scoped to the owning session.

6. CSP Header Analysis

Content-Security-Policy headers across all subdomains revealed five internal AWS S3 bucket names. Direct access testing on all five returned AccessDenied — all buckets are properly private.

Additionally, an internal development endpoint (ai-assistant-dev.eureka.us-west-2.dev.23andme.net) was found referenced in the production CSP frame-src directive — out of scope for testing but noted as information disclosure.

7. Findings Summary

8. Security Observations

23andMe's authorization architecture reflects a deliberate design decision: session-based identity that ignores client-supplied object references entirely. Profile ID enumeration — whether through manual manipulation or automated fuzzing — produces no cross-account data access because the server does not use the client-provided ID as the authorization source. This is the correct design for a platform storing sensitive genetic and health data.

The Cloudflare WAF integration on auth.23andme.com is configured with active rule tuning — administrative paths trigger managed challenges rather than flat blocks. This reflects deliberate security configuration rather than default settings.

The primary residual risk surface from this assessment is client-side information disclosure. The feature flag system and CSP headers expose more of the internal architecture than necessary — this type of intelligence disclosure is often the precursor to more targeted attacks on less-scrutinized features.

The Mapbox token warrants further scope verification. If configured beyond read-only, it represents a low-cost, externally-visible resource that could be abused to generate charges against 23andMe's account.

9. Responsible Disclosure

All testing was conducted within 23andMe's authorized HackerOne bug bounty program. Test accounts were created using the HackerOne email alias per program requirements. All requests included the X-HackerOne-Research: leenadeeb header. No real user data was accessed or retained.

Specific identifiers (profile IDs, session tokens, account IDs) have been redacted. This writeup describes testing methodology and security observations — not specific exploitable vulnerabilities — and is published for professional portfolio purposes consistent with the program's disclosure policy.

If this writeup was useful, follow on HackerOne (leenadeeb) for future research publications.

Leen Adeeb is a security researcher specializing in Cyber Threat Intelligence and web application security testing.
HackerOne: leenadeeb