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

  1. 01API keys baked into the bundle from EXPO_PUBLIC_ env vars (designed to be public — but treat critical keys as server-only)
  2. 02Missing CSP/HSTS on the deployed web target
  3. 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.

Run a Expo security scan

Free. 70+ checks. 60 seconds.