How I Would Fix exposed API keys and missing auth in a Make.com and Airtable client portal Using Launch Ready.

Opening

If I saw exposed API keys and missing auth in a Make.com and Airtable client portal, I would assume two things first: the portal is already one browser refresh away from data exposure, and the team has probably been shipping too fast without a security boundary. The most likely root cause is that Airtable is being used as both database and access layer, while Make.com scenarios are calling it with long-lived secrets that ended up in frontend code, shared links, or logs.

The first thing I would inspect is the public surface area. I want to know exactly what a logged-out visitor can see, which endpoints are callable without a session, and whether any Airtable bases, Make webhooks, or environment variables have been exposed in the browser bundle, deployment settings, or shared automation links.

Triage in the First Hour

1. Check the live portal in an incognito window.

• Try every major page without logging in.
• Confirm whether customer records, invoices, files, or internal notes are visible.

2. Inspect browser network calls.

• Open DevTools and look for Airtable base IDs, table names, Make webhook URLs, or API tokens in requests and responses.
• Verify whether any secrets are present in JS bundles or inline config.

3. Review deployment environment variables.

• Check Vercel, Netlify, Cloudflare Pages, Railway, or similar hosting settings.
• Confirm whether keys were stored as public variables by mistake.

4. Audit Make.com scenarios.

• Identify all inbound webhooks and outbound HTTP modules.
• Confirm whether any scenario can be triggered without auth or validation.

5. Audit Airtable sharing settings.

• Check if the base is shared publicly, embedded somewhere unsafe, or connected through a weak personal token.
• Verify table-level permissions are not being assumed where none exist.

6. Review logs and error traces.

• Look at app logs, Make run history, Cloudflare logs, and server logs for leaked payloads or failed auth attempts.
• Search for tokens in stack traces or debug output.

7. Freeze risky changes.

• Pause automations that write customer data until access control is confirmed.
• Disable any public forms or open webhooks tied to production data.

8. Snapshot current state.

• Export current scenario mappings, Airtable schema, and deployment config before changing anything.
• This avoids making recovery harder if something breaks during cleanup.

## Quick secret sweep in a frontend repo
grep -RniE "airtable|make\.com|webhook|api[_-]?key|secret|token" .

Root Causes

| Likely cause | How I confirm it | Business risk | |---|---|---| | API key hardcoded in frontend code | Search built assets and source maps for tokens | Anyone can read or write customer data | | Make webhook exposed with no verification | Hit webhook URL without a signed request or auth header | Unauthorized writes and spam automation runs | | Airtable base used as public backend | Check sharing settings and anonymous access paths | Data leakage across all clients | | Missing portal authentication | Open client pages without session checks | Anyone can view private records | | Weak role checks after login | Log in as one user and try another client's record ID | Cross-account data exposure | | Secrets stored in client-side env vars | Inspect build output for public runtime variables | Keys become visible to every visitor |

The most common pattern I see is "security by obscurity." The founder assumes nobody will find the endpoint because it sits behind a nice UI. That fails fast once the app gets traffic, gets indexed incorrectly, or gets copied into support tickets and screenshots.

The Fix Plan

My rule here is simple: stop the leak first, then restore access control with the smallest safe change set possible. I do not try to redesign the whole portal during an incident unless the architecture itself is unsalvageable.

1. Rotate every exposed secret immediately.

• Revoke Airtable personal access tokens, Make connections, API keys, webhook secrets, email provider keys, and any admin credentials that may have leaked.
• Assume anything seen in browser code or logs is compromised.

2. Cut off unauthenticated access paths.

• Put the portal behind real authentication before it can load private data.
• If there is no auth system yet, add one now rather than patching around it with hidden URLs.

3. Move secrets out of the browser.

• All Airtable writes should happen from server-side routes or secure automation steps only.
• The frontend should never hold master credentials.

4. Add request verification on every automation entry point.

• Require signed headers, session validation, CSRF protection where relevant, or short-lived tokens for form submissions and webhooks.
• Reject requests that do not match expected origin and identity.

5. Lock down Airtable usage.

• Use a dedicated service account pattern where possible.
• Restrict base access to only what Make.com needs for its job.

6. Add authorization checks at record level.

• A logged-in user must only see their own records based on tenant ID, account ID, or client email mapping.
• Never trust query params alone for record selection.

7. Sanitize logs and scenario outputs.

• Remove tokens from debug output in Make.com mappings and app logs.
• Keep only enough detail to troubleshoot without exposing customer data.

8. Add Cloudflare protection at the edge if applicable.

• Turn on WAF rules where useful.
• Enable rate limiting on login and webhook endpoints to reduce brute force noise and accidental abuse.

9. Deploy with environment separation.

• Separate dev and prod Airtable bases if needed.
• Separate Make scenarios so test traffic cannot mutate production records.

10. Re-test before turning traffic back on.

• Do not re-enable public flows until auth failures behave correctly and private records stay private under every tested path.

Regression Tests Before Redeploy

I would treat this like a release gate instead of a casual QA pass. The goal is not just "does it work," but "can an unauthorized person get anything useful."

Acceptance criteria:

• Anonymous users cannot view any client-specific page or record list.
• Anonymous users cannot trigger protected Make.com scenarios.
• Authenticated users can only see their own records.
• No API keys appear in browser source code, network responses, logs, or build artifacts.
• Failed auth attempts return safe errors without leaking internal details.
• Rate limits block repeated unauthorized hits on sensitive endpoints.

Test plan:

1. Run an incognito walkthrough of the entire portal flow. 2. Attempt direct record access with guessed IDs from another account context. 3. Replay intercepted requests without valid session headers to confirm rejection. 4. Verify every webhook rejects unsigned or malformed requests with 401 or 403 responses. 5. Confirm Airtable queries return only scoped records for that user or tenant. 6. Check mobile views too; broken responsive states often hide auth bugs behind different routes or components. 7. Validate error states so users do not get stuck on blank screens after denied access.

I would also want basic observability before shipping:

• alert on repeated 401s/403s,
• alert on unusual Make run volume,
• alert on failed scenario executions,
• track p95 response time under 500 ms for portal pages that fetch private data,
• keep uptime monitoring active so we catch broken auth redirects quickly after deploy.

Prevention

Security problems like this usually come back because nobody owns them after launch. I prevent that by putting guardrails into process as well as code.

• Code review:
• No secrets in frontend code ever.
• No new endpoint ships without auth review and least privilege checks.

• Security:
• Rotate secrets quarterly at minimum after launch stabilization period ends there should be no "forever" tokens sitting around unused but valid

-, use separate prod credentials, -, limit who can edit Make scenarios, -, store sensitive values only in server-side env vars, -, log security events without logging raw secrets

• UX:
• Show clear login states instead of silent failures

-, explain when access is denied -, make account boundaries obvious so users understand why they cannot see another client's data

• Performance:

-.cache static assets behind Cloudflare -, keep third-party scripts minimal -, avoid loading full Airtable datasets into the browser -, fetch only scoped records so pages stay fast even as data grows

• Monitoring:

-.watch uptime, -.watch auth failure spikes, -.watch automation run counts, -.review logs weekly until behavior stabilizes

A simple rule I recommend: if a secret must exist to serve a page safely then that secret belongs on the server side only. If it can be copied into JavaScript once then it will eventually be copied into places you did not intend.

When to Use Launch Ready

Use Launch Ready when you need me to stop exposure quickly and get the portal back into a safe production state within 48 hours. It fits best when you already have a working build but need domain setup,, email authentication,, SSL,, Cloudflare,, deployment,, secrets handling,, monitoring,,and handover cleaned up before customers touch it again.

What I expect you to prepare:

• Access to hosting,, domain registrar,, Cloudflare,, Airtable,,Make.com,,and any email provider
• A list of all live environments
• Any known broken flows
• A short description of who should see what inside the portal
• Confirmation of which automations are allowed to write production data

Delivery Map

References

1. Roadmap.sh Cyber Security Best Practices: https://roadmap.sh/cyber-security 2. Roadmap.sh API Security Best Practices: https://roadmap.sh/api-security-best-practices 3. Roadmap.sh QA: https://roadmap.sh/qa 4. Airtable Security Documentation: https://support.airtable.com/ 5. Make Help Center: https://www.make.com/en/help

---

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.*