How I Would Fix exposed API keys and missing auth in a React Native and Expo AI-built SaaS app Using Launch Ready.

How I Would Fix exposed API keys and missing auth in a React Native and Expo AI-built SaaS app Using Launch Ready

The symptom is usually ugly but simple: the app works, users can sign up, and then someone notices the API key is sitting in the mobile bundle, or worse, the app lets anyone hit paid endpoints without logging in. In an AI-built React Native and Expo SaaS app, the most likely root cause is that backend rules were assumed instead of enforced, and secrets were shipped into the client because it was the fastest way to get a demo working.

The first thing I would inspect is the Expo config, the app bundle entry points, and every place the app calls your API directly. I want to know whether secrets are in `app.config.js`, `.env`, EAS build profiles, or hardcoded in source, and whether auth is only handled in the UI instead of on the server.

Triage in the First Hour

1. Check the live app behavior on a fresh device.

• Can I open protected screens without signing in?
• Can I call paid or private endpoints after clearing storage?
• Does logout actually revoke anything server-side?

2. Inspect deployed client code.

• Search for `API_KEY`, `SECRET`, `Bearer`, `Authorization`, `supabaseKey`, `firebaseConfig`, or vendor tokens.
• Review any public GitHub repo history if it exists.
• Check whether environment variables were baked into the Expo build.

3. Review backend logs and auth events.

• Look for anonymous requests to protected routes.
• Check failed login counts, token reuse, and unusual traffic spikes.
• Confirm whether middleware is rejecting unauthenticated access.

4. Inspect cloud and vendor dashboards.

• API provider usage metrics.
• Billing spikes from key abuse.
• Any rate limit alerts or blocked requests.

5. Review EAS and deployment settings.

• Build profiles.
• Environment variable scopes.
• Secrets stored in CI, EAS, GitHub Actions, or Vercel-like services.

6. Check user-facing screens.

• Login flow.
• Deep links into authenticated areas.
• Empty states that accidentally reveal data before auth completes.

7. Freeze risky changes.

• Pause new releases until secret exposure is contained.
• If abuse is active, rotate keys before touching UI polish.

A simple command I would run locally during triage:

grep -RInE "API_KEY|SECRET|Bearer|Authorization|supabase|firebase|openai|anthropic" .

That does not solve anything by itself, but it quickly shows whether the app was built with secrets in places they should never have been.

Root Causes

1. Secrets were placed in the mobile client.

• Confirmation: inspect Expo config files and bundled JS output for live credentials.
• Why it happens: founders often use one key for speed during prototype work.

2. Auth exists only in the UI layer.

• Confirmation: try calling private endpoints directly with curl or from a clean device session.
• Why it happens: screens are hidden behind login buttons, but APIs still accept requests anonymously.

3. Backend authorization checks are missing or inconsistent.

• Confirmation: compare route handlers against intended permissions for user, admin, and tenant-scoped data.
• Why it happens: developers add auth on one endpoint and assume adjacent endpoints inherit it.

4. Tokens are not validated properly.

• Confirmation: check expiry handling, signature verification, audience checks, issuer checks, and refresh flow behavior.
• Why it happens: quick demos often trust decoded tokens without verifying them correctly.

5. Build-time environment variables were exposed through Expo/EAS misconfiguration.

• Confirmation: review build logs, published updates, `.env` usage, and what values ended up in JS bundles.
• Why it happens: frontend env vars are treated like server secrets when they are not.

6. Third-party services were connected with overprivileged keys.

• Confirmation: inspect vendor roles and permissions for database access, email sending, storage writes, or AI usage limits.
• Why it happens: one master key gets used everywhere instead of scoped service accounts.

The Fix Plan

My approach is to contain first, then repair access control at the backend boundary, then clean up secrets so this does not recur.

1. Rotate exposed keys immediately.

• Revoke every key that may have shipped to the client or appeared in logs.
• Replace them with least-privilege keys scoped to only what each service needs.

2. Move all sensitive operations behind server endpoints.

• The mobile app should never talk directly to privileged APIs with secret credentials embedded inside it.
• If the app needs OpenAI, database writes, email sending, or file access with privileged scope, route that through your backend.

3. Enforce authentication on every protected route server-side.

• Add middleware that rejects missing or invalid tokens before any business logic runs.
• Do not rely on screen guards alone because they only affect UX, not security.

4. Enforce authorization per resource.

• A valid user should only access their own tenant data unless explicitly granted otherwise.
• Check ownership at query time, not just at login time.

5. Clean up token handling in React Native and Expo.

• Store session tokens securely using platform-safe storage such as SecureStore where appropriate for your architecture.
• Remove any token persistence that leaks into plain AsyncStorage if your risk profile does not allow it.

6. Remove secrets from client bundles and public repos.

• Move private values into server env vars and CI secret stores only where needed.
• Purge old commits if necessary after rotation so you do not leave a future breach path lying around.

7. Add request throttling and abuse controls now.

• Rate limit login attempts and expensive endpoints.
• Add IP-based or account-based throttles if AI calls or paid operations can be triggered repeatedly.

8. Add audit logging without leaking sensitive data.

• Log auth failures, permission denials, token refreshes, and unusual request volume.
• Never log full tokens or raw secrets because that creates a second incident while fixing the first one.

Here is the decision path I would follow:

My recommendation is to make one safe pass instead of patching around symptoms. A half-fix usually leaves a hidden endpoint open while making everyone feel better because the login screen looks correct again.

Regression Tests Before Redeploy

Before I ship anything back to production, I want proof that unauthorized access fails consistently and legitimate users still work normally.

• Authentication tests
• Anonymous requests to protected routes return `401`.
• Invalid tokens return `401`.
• Expired tokens require re-authentication or refresh as designed.

• Authorization tests

```text User A cannot read User B records User A cannot update User B resources Admin-only routes reject normal users ``` Acceptance criteria: + Every protected route has a failing unauthenticated test case + Every multi-tenant route has an ownership test case

• Secret exposure tests

```text grep bundle output for live secrets = none found ``` Acceptance criteria: + No private key appears in client source or compiled bundle + No secret appears in logs, crash reports, analytics payloads, or error screens

• Mobile flow tests

+ App opens correctly after logout/login cycles on iOS and Android simulators + Deep links do not bypass auth checks + Offline state does not reveal private data from cache

• Security edge cases

+ Token refresh failure sends user back to sign-in cleanly + Rate-limited login attempts show a safe error message + Permission denied responses do not expose internal IDs or stack traces

• Release gate targets

+ Zero exposed secrets in production build artifacts + Auth coverage on protected routes at least 90 percent for critical paths + No unauthenticated access found in manual smoke testing across top user journeys

If this is an AI-built SaaS app with automated prompts or tool use inside it too long-term risk rises fast because bad auth becomes data exposure plus uncontrolled spend. I would treat prompt injection defenses separately if AI tools can read user content or trigger actions on behalf of users.

Prevention

I would put guardrails around code review first because this class of bug usually comes from speed without boundary checks.

• Code review rules

+ Never approve a mobile PR that includes real secrets + Every new endpoint must specify auth requirements explicitly + Every write path must include ownership checks

• Security controls

+ Use least privilege for every external service key + Rotate keys on a schedule and after incidents + Keep rate limiting on login and expensive AI endpoints

• Monitoring controls

+ Alert on spikes in anonymous traffic to protected routes + Alert on unusual token failures or refresh storms + Alert on vendor billing spikes from API abuse

• UX controls

+ Make sign-in state obvious across all screens + Show clear loading/error states during session validation so users do not assume they are authenticated when they are not

• Performance controls tied to security hygiene

+ Avoid shipping large debug SDKs that leak data into logs + Remove unused third-party scripts from web views or landing pages connected to auth flows

I also want a small release checklist before every deploy: 1. Secrets scan passes, 2. Auth tests pass, 3. Permission tests pass, 4. Logging reviewed, 5. Rollback plan ready, 6. Monitoring live within minutes of release.

When to Use Launch Ready

Launch Ready fits when you need this fixed fast without turning it into a two-week rescue project. Actually for this sprint specifically you get production deployment support plus environment variables management secrets handling uptime monitoring SSL Cloudflare caching DDoS protection SPF DKIM DMARC redirects subdomains and handover checklist within one tight window so you can stop shipping insecure builds while you stabilize the product.

Use Launch Ready if:

• You have an Expo React Native SaaS app already working but unsafe,
• You need secrets removed before more users install it,
• You want auth enforced before ads spend starts,
• You need a clean handoff after a messy AI build,
• You want production monitoring so regressions get caught early instead of by customers.

Prepare these items before kickoff:

• Repo access plus branch strategy,
• EAS account access,
• Backend/admin console access,
• Current list of env vars and third-party services,
• Any known incidents or suspicious billing spikes,
• Desired roles such as free user versus paid user versus admin,
• One person who can approve decisions quickly during the sprint window,

My opinionated advice: do not keep iterating features until this is fixed at the boundary layer. Broken auth plus exposed keys means every new feature increases support load, abuse risk, downtime risk under load patterns nobody planned for yet maybe failed app review if mobile policies are violated due to insecure data handling too..

References

• https://roadmap.sh/api-security-best-practices
• https://roadmap.sh/cyber-security
• https://roadmap.sh/code-review-best-practices
• https://roadmap.sh/qa
• https://docs.expo.dev/

---

Take the next step

If this is a problem in your product right now, here is what to do next:

• [Use the free Cyprian tools](/tools) - estimate cost, score app risk, check launch readiness, or pick the right service sprint.

• [Book a discovery call](/contact) - I will tell you honestly whether you need a sprint or if you can DIY the next step.

*Written by Cyprian Tinashe Aarons - senior full-stack and AI engineer helping founders rescue, launch, automate, and scale AI-built products.*