You pushed the feature. The app works. Supabase or Firebase is wired up, the mobile build passed, and users can finally sign in, save data, and hit your new endpoint.
That’s usually the moment teams relax. It’s also the moment they stop looking closely at the API.
In early-stage products, most security failures don’t come from some exotic zero-day. They come from ordinary shipping pressure. A policy is too broad. A callable function trusts client input. A table meant for internal use is reachable through an RPC. Someone assumes the SDK will enforce access control because the UI does. It won’t.
For startup teams, security testing api work has to fit the way you build. Fast releases, small teams, backend-as-a-service defaults, and limited time for manual review. Generic API advice often stops at REST endpoints and bearer tokens. That misses the key trouble spots in modern BaaS stacks: Row Level Security, exposed database functions, permissive storage rules, and business logic that lives partly in the client and partly in managed backend services.
Why API Security Gets Overlooked in Modern Development
A small team ships differently from an enterprise team. One person owns the schema, another tweaks mobile auth, someone else adds a serverless function at midnight, and by morning the feature is live. That speed is the advantage. It’s also how risky API behaviour slips into production unnoticed.
Supabase and Firebase make it easy to get a backend online. That’s why so many teams choose them. But convenience changes where the mistakes happen. Instead of hand-rolled middleware bugs, you get policy mistakes, weak rules, overexposed functions, and trust boundaries that aren’t obvious until you test them directly.
Fast shipping hides API risk
Most founders and indie hackers prioritise what users can see. Login flow. Search. Sync. Billing. Security checks often get deferred because nothing appears broken. The app behaves correctly in normal use, so the backend feels safe.
Attackers don’t use the app normally. They change identifiers, replay requests, strip auth headers, call functions directly, and test paths your frontend never exposes. A polished UI can sit on top of an API that leaks data with a single modified request.
Practical rule: if the client can send it, a malicious client can change it.
That’s especially relevant in BaaS setups, where developers often rely on client-side filtering or assume generated SDK calls imply correct authorisation. They don’t. The backend has to enforce every access decision.
Default isn’t the same as secure
A lot of teams treat managed platforms as if secure defaults cover the whole problem. They help, but they don’t remove the need for testing. A permissive RLS policy in Supabase is still permissive. A Firebase rule that’s broad enough to make development easy is also broad enough to expose production data.
The content gap around these platforms is real. According to analysis of BaaS security blind spots in UK startup stacks, 68% of UK startup stacks run on platforms like Supabase and Firebase, and a 2025 UK Tech Nation report found 42% suffered API breaches from untested BaaS endpoints. The same analysis argues that most advice still ignores checks such as fuzzing RLS logic and finding unprotected RPCs, even though manual testing can miss much of this dynamic behaviour.
What that means in practice
For modern teams, API security isn’t a later hardening pass. It’s part of release quality.
A feature isn’t done when the happy path works. It’s done when you know:
- User isolation holds when IDs are tampered with
- Functions reject unauthorised callers even without the frontend
- Rules match the intended business model rather than the easiest development shortcut
- Error paths don’t leak internals that help an attacker map your system
If you build on BaaS, your biggest wins come from testing the logic beneath the SDK, not admiring the speed of the dashboard.
Building Your API Threat Model Before You Test
Hearing “threat model” often brings to mind a heavy enterprise exercise with long workshops and diagrams nobody updates. For a startup, it should be much simpler. List what can be reached, who should be allowed to reach it, and what would hurt if that assumption fails.
That exercise matters because teams often don’t have a clear inventory. In the UK, 84% of security professionals reported an API breach in the past 12 months, while only 27% of UK respondents maintained a full API inventory, down from 40% in 2023, according to the Akamai API security findings for the UK. The same source notes Gartner’s view that average API breaches leak at least 10 times more data than typical security incidents. If you don’t know your real API surface, your testing will be shallow by definition.
Start with assets, not tooling
Write down the parts of the app that matter most:
- Identity data such as profiles, emails, roles, and auth-linked records
- Customer content like notes, files, messages, orders, or reports
- Sensitive workflows including checkout, invitation flows, admin actions, and account recovery
- Backend-only operations exposed through RPCs, cloud functions, or edge functions
Then mark where each asset is reachable. In a Supabase project, that usually means tables, views, storage buckets, and database functions. In Firebase, it means Firestore or Realtime Database paths, Storage, and callable or HTTP-triggered functions.
Map common API risks to BaaS behaviour
You don’t need a perfect model. You need a useful one. A simple mapping works well:
| API risk | Supabase example | Firebase example | |---|---|---| | Broken Object Level Authorization | RLS policy allows access to another user’s row | Rules allow reads or writes outside a user-owned path | | Security misconfiguration | Public RPC exposed without strict checks | Database or Storage rules too permissive | | Broken function-level authorisation | Role-sensitive RPC callable by ordinary users | Callable function trusts client flags for admin actions | | Excessive data exposure | Query returns columns the client never needs | Function or rule exposes extra fields | | Injection or unsafe input handling | RPC builds unsafe queries or trusts raw parameters | Function passes unsanitised input into downstream logic |
This is the point where many teams realise they’ve been testing the client rather than the API. That’s backwards.
Threat modelling for security testing api work should answer one question clearly: what can an authenticated but curious user do if they start changing requests?
Build a lean risk map
Use a one-page sheet. For each endpoint, function, table, or rule set, note:
- Who can call it
- What object or record it touches
- What check is supposed to enforce access
- How you’d try to break that check
For example, if orders should only be visible to the owner, the test idea is obvious: authenticate as one user and attempt to read another user’s order by changing the identifier. If an admin-only function updates billing state, try calling it with a normal user token or without the expected role claim.
If you want a practical companion for design and review, this guide to API security best practices for modern teams is worth keeping next to your backlog. The important part isn’t the document. It’s forcing each risky path to have an explicit ownership and enforcement story.
Prioritise what deserves immediate testing
Don’t test in alphabetical order. Test where failure creates the biggest blast radius:
- Anything that crosses tenant boundaries
- Anything tied to money, permissions, or private content
- Anything callable without the normal UI flow
- Anything added quickly and not reviewed after launch
A threat model isn’t paperwork. It’s how you stop guessing.
The Essential API Security Testing Checklist
Threat models tell you where to look. A checklist keeps you from missing the predictable failures that show up over and over in Supabase and Firebase projects.
Generic API guidance often becomes too broad. It tells you to test auth, validation, and rate limits. Fine. But BaaS stacks need more specific checks, especially around generated APIs, RLS, rules engines, and serverless functions. That gap matters because, as noted in the earlier section, much of the common advice doesn’t reflect how these backends fail.
Authentication and authorisation
Start here because a lot of serious exposure exists here.
- Token handling: Test requests with missing, expired, malformed, and replayed tokens. You’re checking that every sensitive path fails closed.
- User-to-user isolation: Change object IDs, foreign keys, and path parameters to verify one user can’t access another user’s records.
- Role enforcement: If you have admin, staff, or paid-tier behaviour, remove the UI from the equation and call the endpoint directly.
In Supabase, the most common mistake is assuming the existence of RLS means the policy is correct. Test both read and write paths. A policy that blocks reads but allows updates through a broad condition is still broken.
Input validation and RPC safety
Database functions and cloud functions often get less scrutiny than obvious endpoints. They shouldn’t.
Check:
- Parameter tampering: Send valid structure with invalid semantics. Negative amounts, swapped user IDs, unexpected enums, oversized strings.
- Schema drift: If the client assumes one shape and the backend accepts broader input, attackers will use the broader input.
- Unsafe query construction: Review custom SQL and serverless code for places where input influences queries or command paths in unsafe ways.
A useful pattern is to test the function twice. First with expected app input. Then with inputs a normal user would never send through the UI.
Field note: business logic bugs often look harmless in code review because every single line seems reasonable on its own.
Error handling and sensitive data exposure
Good APIs fail clearly for developers and vaguely for attackers.
Use the checklist below during manual review or runtime testing:
- Verbose errors: Trigger failures and inspect whether responses expose schema names, stack traces, internal function names, or auth details.
- Over-returned data: Compare the response with what the screen requires. If the API returns more, reduce it.
- Leaky logs: Make sure tokens, personal data, and secrets aren’t being written to application logs or analytics payloads.
- Storage access: Verify bucket or file permissions align with ownership rules, especially for user uploads and generated exports.
Rate limiting and abuse resistance
A secure app can still be easy to abuse.
Test for:
- Credential stuffing resistance on login and password reset flows
- Brute-force protection on one-time codes and invitation links
- Function abuse where expensive endpoints can be hit repeatedly
- Enumeration on usernames, emails, IDs, and invite tokens
Firebase callable functions and edge functions are common abuse targets because teams focus on correctness, not volume or automation. An endpoint that enforces auth but allows unlimited retries still creates risk.
Security misconfiguration and hidden surface area
Some of the worst bugs are the boring ones.
Look for:
- Old endpoints still reachable
- Debug or test functions left deployed
- Public rules that were meant only for local development
- Unused RPCs that still have production privileges
- Frontend bundles exposing keys or internal endpoint names
The checklist works best when paired with an inventory review. Features die in the UI long before they die in the backend.
Logging that helps during an incident
If something goes wrong, logs should tell you what happened without leaking data themselves.
A practical standard:
| Logging question | Good outcome | |---|---| | Can you tie requests to an actor? | User or service identity is recorded | | Can you reconstruct abuse? | Endpoint, action, and timestamp are visible | | Are secrets excluded? | Tokens and raw credentials are not logged | | Are denials visible? | Failed auth and blocked actions are recorded |
A checklist isn’t glamorous. It is effective. Many teams don’t need more theory. They need a repeatable habit that catches the same classes of mistakes every release.
Choosing Your API Testing Tools and Methods
Security testing api work usually starts with whatever the team already has. That’s often a proxy tool, a few saved requests, and a lot of manual clicking. There’s value in that. It teaches you how the application behaves. It also reaches its limit quickly once your backend grows beyond a handful of obvious endpoints.
The hard part is choosing the right mix of methods, not pretending one method does everything.
Manual testing still matters
Burp Suite, OWASP ZAP, Postman, Insomnia, and browser devtools are still useful. They let you inspect requests, replay edge cases, and understand flows in a way automated scanners can’t fully replace.
Manual work is especially good for:
- Learning the app’s trust boundaries
- Exploring unusual business logic
- Checking whether findings are real and exploitable
- Reviewing how the client and backend interact under normal use
But manual review has obvious limits. It’s slow, inconsistent, and dependent on whoever has the patience to keep mutating requests after they’ve already found one bug.
Where manual methods break down
BOLA testing is the clearest example. It looks easy. In reality, it requires systematic variation across users, object IDs, roles, and function inputs. That’s exactly where humans get tired and scanners don’t.
A 2025 NCSC-related benchmark on API testing methods reported that manual penetration testing misses 68% of BOLA flaws, while automated AuthN/Z fuzzing reached 92% detection success for BOLA, particularly with Supabase RLS policies. That doesn’t mean manual testing is useless. It means relying on it as the primary control for authorisation flaws is inefficient.
Manual review finds patterns. Automation finds coverage.
Generic scanners versus stack-aware tools
Not all automation is equal.
A generic DAST scanner can hit documented endpoints and look for broad classes of flaws. That’s helpful for common web patterns. It’s less helpful when the underlying problem is a permissive RLS policy, a callable function that trusts a client-supplied role, or a public RPC that only becomes dangerous when you fuzz ownership logic.
When comparing tools, focus on fit:
| Tool type | Strength | Weakness | |---|---|---| | Proxy-based manual tools | Great for understanding flows and reproducing bugs | Slow and hard to scale | | Generic API DAST | Useful baseline for common endpoint issues | Often shallow on BaaS-specific logic | | Static analysis | Good for hardcoded secrets and obvious code smells | Misses runtime access control failures | | Stack-aware API scanners | Better at testing policies, auth logic, and dynamic backend behaviour | Requires you to choose one that matches your stack |
For many teams, the core choice isn’t manual versus automated. It’s whether your automation understands the backend you run. If your data layer depends on RLS and generated APIs, your scanner should be able to test those mechanics directly.
If you’re weighing where static and dynamic approaches fit, this breakdown of SAST vs DAST for modern application security is a useful reference. In practice, most startup teams need both, but they shouldn’t expect static checks to prove that runtime authorisation is safe.
What a good tool should prove
A useful testing tool shouldn’t just say “possible issue”. It should help answer:
- Can one user read another user’s data?
- Can one user write another user’s data?
- Can a public or low-privilege caller hit a sensitive function?
- Does the frontend expose secrets or privileged endpoints?
- Can the issue be reproduced with a concrete request?
That last part matters. Developers fix faster when the evidence is direct.
For startup teams, the best tooling combination is usually simple. Manual tooling for understanding and validation. Automated, stack-aware testing for breadth, repetition, and CI/CD. Anything else either wastes time or leaves dangerous gaps.
Automating Security Scans in Your CI/CD Pipeline
One-off testing catches today’s mistakes. CI/CD catches the mistakes you’re about to merge.
That shift matters because API security problems often appear during ordinary feature work. A new edge function trusts the caller too much. A Firestore rule gets widened to unblock testing. A policy change fixes one path and accidentally opens another. If scanning only happens before a major release, those regressions sit in production until someone notices.
What to automate first
Start with the checks most likely to break during normal development:
- Auth and access control tests for sensitive endpoints
- RLS or rule validation for user-owned data paths
- Function exposure checks for RPCs, callable functions, and edge functions
- Secret leakage checks in frontend bundles and mobile builds
Run them on pull requests for fast feedback, then again on merge to your main branch for a cleaner gate.
A practical pipeline shape
A lightweight approach works well for small teams:
- Trigger on pull request or push
- Deploy a preview or test environment
- Run API security scans against that environment
- Fail the workflow on critical findings
- Post the result into the PR so the developer sees it immediately
If your team already treats tests as release criteria, this fits naturally. Security findings become another category of failing build, not a separate process hidden in someone’s backlog.
A lot of teams also benefit from tightening how they handle prompts and generated code in the same delivery flow. If AI-assisted development is part of your process, this guide to Prompt Builder for prompt development is useful because it treats prompt changes with the same versioning and CI discipline you’d apply to code. That mindset carries over well to API security. Generated code can introduce backend risk just as quickly as handwritten code.
Keep the gate strict but usable
Don’t fail every build for every minor issue. Teams stop trusting gates that constantly block work for noise.
A better model is:
- Block immediately on confirmed high-impact access control failures
- Warn but don’t block on lower-confidence findings that need review
- Track regressions so a previously fixed issue doesn’t recur
CI security works when developers get feedback while the change is still fresh, not two sprints later in a PDF report.
Make findings actionable inside the workflow
The output should include the exact endpoint, the failing request pattern, the expected behaviour, and a remediation hint. If a developer has to open three tools and ask security what the result means, the pipeline is too indirect.
For implementation ideas, this walkthrough on CI/CD security testing workflows for modern teams gives a practical model. The key principle is simple. Security checks have to behave like engineering checks. Fast enough to run regularly. Clear enough to act on. Strict enough to matter.
From Findings to Fixes with Actionable Remediation
A scan report is only useful if it shortens the path to a fix. That sounds obvious, but many teams still get findings that say little more than “authorisation issue possible”. Developers then waste hours reproducing the bug before they can even start remediation.
That’s the wrong workflow. Security testing api efforts should end with a concrete change list.
The operational case for faster remediation is strong. According to UK startup API breach findings published with BCS data, 74% of startups suffered API breaches, with authentication failures causing 52%. The same source says actionable SQL snippets for RLS fixes and continuous scanning can reduce MTTR from weeks to minutes, with a 67% compliance lift. That’s the difference between “we know there’s a problem” and “we closed it before the next deploy”.
Fixing an overbroad Supabase RLS policy
A common failure looks like this: authenticated users can query a table, but the policy doesn’t tie the row to the current user.
Bad pattern:
create policy "authenticated users can read profiles"
on public.profiles
for select
to authenticated
using (true);
That policy allows any authenticated user to read every row.
Safer pattern:
create policy "users can read their own profile"
on public.profiles
for select
to authenticated
using (auth.uid() = user_id);
The same principle applies to updates:
create policy "users can update their own profile"
on public.profiles
for update
to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);
Two details matter here. using controls which existing rows are targetable. with check controls what new row state is allowed after the write. Teams often set one and forget the other.
Fixing an unprotected Supabase RPC
An RPC can bypass your intended access model if it runs privileged logic without validating the caller.
If you have a function that updates an order, don’t trust a client-supplied user_id. Resolve identity from auth context inside the function and enforce ownership in the query condition.
Better pattern:
create or replace function public.update_order_status(target_order_id uuid, new_status text)
returns void
language plpgsql
security invoker
as $$
begin
update public.orders
set status = new_status
where id = target_order_id
and user_id = auth.uid();
end;
$$;
If a function truly requires higher privileges, treat it like privileged code. Add narrow checks, minimise scope, and test it with low-privilege callers.
Fixing a Firebase callable or HTTP function
A lot of Firebase issues come from trusting the client because the frontend only exposes the function to signed-in users. Attackers won’t use the frontend.
For a callable function, verify auth before doing anything sensitive:
exports.updateProfile = functions.https.onCall(async (data, context) => {
if (!context.auth) {
throw new functions.https.HttpsError('unauthenticated', 'Sign-in required');
}
const uid = context.auth.uid;
const targetUid = data.uid;
if (uid !== targetUid) {
throw new functions.https.HttpsError('permission-denied', 'Cannot modify another user profile');
}
// proceed with constrained update
});
For HTTP-triggered functions, validate the token server-side and derive identity from it. Don’t accept identity fields from the request body as the source of truth.
Turn findings into developer-ready tasks
Good remediation guidance should tell the developer four things:
-
What failed
Example: user A could read user B’s order by changing the order ID. -
Why it failed
Example: policy checked authentication but not ownership. -
What to change
Example: addauth.uid() = user_idto read and write policy conditions. -
How to verify the fix
Example: repeat the same request with two test users and confirm denial.
The best finding format reads like a pull request review comment, not a vague warning.
Fix fast, then retest the exact path
Don’t stop at “policy updated”. Re-run the same exploit attempt. Then test neighbouring paths. If read was broken, test update and delete too. If a callable function trusted one field from the client, inspect the rest of the payload for similar assumptions.
That cycle is what moves a team from reactive patching to confidence. Not more dashboards. Better fixes, verified quickly.
If you’re building on Supabase, Firebase, or shipping a mobile app with a managed backend, AuditYour.App gives you a fast way to find exposed RLS rules, public RPCs, leaked keys, and backend misconfigurations without the usual setup overhead. Paste a project URL, app build, or site, run a scan, and get concrete findings with remediation guidance that helps your team fix real issues quickly.
Scan your app for this vulnerability
AuditYourApp automatically detects security misconfigurations in Supabase and Firebase projects. Get actionable remediation in minutes.
Run Free Scan