Expo
Security scanning for Expo web builds
Expo’s mobile-first nature means a lot of code is written assuming "the binary is private". When you ship a web target, that assumption breaks — your bundle is now JS in a browser, fully readable. Run a SafeToShip scan on the web URL to catch what slipped through.
Most common issues
- 01API keys baked into the bundle from EXPO_PUBLIC_ env vars (designed to be public — but treat critical keys as server-only)
- 02Missing CSP/HSTS on the deployed web target
- 03Hardcoded backend secrets in shared utility files
What SafeToShip checks for Expo
- js-secrets
- headers
- cors
- ssl
- exposed-files
FAQ
Frequently asked questions
- Is EXPO_PUBLIC_ safe for the same things NEXT_PUBLIC_ is?
- Same rule of thumb: only for values truly meant to be public (Supabase anon key, Stripe publishable key, Mapbox public token). Server secrets must be reached via your backend, not embedded.
- Do mobile binaries leak secrets too?
- Native binaries are reverse-engineerable. Anything in app.json under "extra" or in EAS Secrets reaches the binary. If a key would leak from a web bundle, treat it as leaking from the mobile binary too.
Fix guides
Common Expo fixes
Hardcoded API key in JS
Any secret in your client bundle is public. Here is how to find them, rotate them, and move the calls server-side.
Read moreMissing CSP header
A missing Content-Security-Policy header lets attackers inject scripts into your site. Here is what CSP does, why you need it, and how to add it in Next.js, Vercel, and Supabase apps.
Read moreMissing HSTS header
HSTS tells browsers to always use HTTPS for your site. Without it, users can be downgraded to HTTP and have sessions stolen. Here is how to add HSTS on Vercel, Next.js, and other hosts.
Read moreExposed .env file
An exposed .env file is a critical leak — it contains API keys, database URLs, and secrets. Here is why it happens in vibe-coded apps and how to lock it down.
Read moreRun a Expo security scan
Free. 70+ checks. 60 seconds.