Security at ShadowPhone
How we protect user data, infrastructure, and device connections — and how to report a vulnerability if you find one.
Security practices
These are the active measures that protect ShadowPhone systems and customer data.
Encryption in transit
All traffic between the ShadowPhone web app, cloud brain, desktop app, and API is encrypted via TLS 1.2+. No unencrypted communication paths exist in production.
Encryption at rest
User data stored in our Supabase-backed database is encrypted at rest using AES-256. Credentials stored in our system are never kept in plaintext.
Authentication
ShadowPhone uses Clerk for authentication. Sessions are token-based with short expiry. API keys are hashed before storage and never returned in full after creation.
Access control
Production database access is gated by Row Level Security (RLS) policies. Users can only read and write data scoped to their own organisation. No shared credential paths exist.
Infrastructure
The cloud brain runs on Railway. The web app deploys via Vercel. Both providers enforce network isolation, automatic DDoS mitigation, and infrastructure-level security hardening.
Dependency management
Dependencies are pinned to known-good versions in CI. We review security advisories regularly and patch high or critical CVEs as a priority. Build pipelines run from a locked lockfile.
ShadowPhone and connected devices
ShadowPhone connects to physical Android phones via ADB (Android Debug Bridge) over USB and Tailscale. Device connections are scoped to the user's own devices — the platform has no path to reach devices belonging to another user.
We recommend users run GrapheneOS on connected phones. GrapheneOS provides strong security hardening, per-profile isolation, and reduced attack surface compared to stock Android. Each user profile on a GrapheneOS phone is an isolated environment.
ADB access over Tailscale is constrained to the user's own Tailscale network. No ShadowPhone staff have access to your connected devices or the actions performed on them.
Responsible disclosure policy
We welcome responsible disclosure from security researchers. If you discover a vulnerability in ShadowPhone, please report it to us so we can fix it before it is publicly disclosed.
In scope
- ✓Authentication and session management vulnerabilities
- ✓Authorisation bypass (accessing another user's data or devices)
- ✓SQL injection or database-level data exposure
- ✓Cross-site scripting (XSS) in authenticated views
- ✓API endpoint vulnerabilities allowing unauthorised data access
- ✓Sensitive data exposure in API responses
- ✓Remote code execution in any ShadowPhone-operated service
Out of scope
- ✕Vulnerabilities in third-party services (Vercel, Railway, Supabase, Clerk)
- ✕Denial of service attacks or load-testing without prior permission
- ✕Social engineering attacks on ShadowPhone staff
- ✕Physical security issues
- ✕Issues requiring compromise of a user's own device first
- ✕Missing HTTP security headers that have no demonstrated exploitability
- ✕Rate limiting on public, unauthenticated endpoints
How to report
- 1.Email security@shadowphone.io with a clear subject line indicating the vulnerability type.
- 2.Include a description of the issue, steps to reproduce, and your assessment of impact.
- 3.Attach any proof-of-concept code, screenshots, or logs that help us reproduce the issue.
- 4.Do not share details publicly until we have confirmed a fix is deployed. We aim to triage within 5 business days.
Security contacts
Vulnerability reports
security@shadowphone.ioAbuse reports
abuse@shadowphone.io