When Incident Reports Say 'Found Traces of Unauthorized Access', What Are They Actually Looking At?

If Your App Gets Attacked, How Would You Even Notice?

Almost every week, we see security disclosure statements that include a familiar line:

"Following an investigation, we confirmed traces of unauthorized data access by a third party."

Every time I read articles like that, a natural question comes to mind: "When they say 'confirmed traces', what are they actually looking at to determine that?"

• "If my own service were attacked, how would I notice?"
• "How do you differentiate malicious scrapers from normal users?"

When you don’t have a dedicated infrastructure or SecOps team, not knowing how to verify facts during a potential incident causes unnecessary anxiety.

Digging through the official documentation for Supabase and Vercel, I organized how I check for traces of suspicious access in a production Next.js + Supabase stack, and what defense layers I keep in place.

1. A Traffic Spike Does NOT Equal Data Leak

Imagine opening your Supabase dashboard one day and seeing a sharp, tower-like spike in Requests or Egress (Data Transfer).

Your heart might skip a beat: "Is our data being scraped right now?!"

However, a traffic surge does not necessarily mean external data theft.

① High Chance It's a Self-Inflicted Bug

Most traffic spikes in small projects aren't external attacks—they are internal issues:

• Client-Side Mistakes: Infinite useEffect dependency loops or overly aggressive polling.
• Large Asset Delivery: Serving uncompressed, raw videos or high-res images directly from Supabase Storage.
• Heavy Queries: Full-table scans repeatedly running due to missing database indexes.
• Database Migrations / Backups: Bulk syncs during active development.

Always start by asking: "Did we push a buggy commit recently?"

② What If It Really Is an External Request Flood?

Even if thousands of requests are hammering your endpoints from an external IP, it’s still too early to assume data was leaked.

This is where RLS (Row-Level Security) acts as your primary shield.

When RLS is configured properly:

• Even if an unauthenticated attacker hits https://<project>.supabase.co/rest/v1/feedbacks?select=*,
• The database returns an empty array [] with zero unauthorized rows.
• Crucially, PostgREST returns this as HTTP 200 OK (empty content) rather than a 403 error.

In other words: Your request count can surge into the tens of thousands while zero user records leave your database (protected by RLS).

Knowing this keeps you calm:

1. Is it an internal infinite loop?
2. If external, did the responses actually contain payload data?

2. Practical Steps to Verify "Traces of Unauthorized Access"

Regardless of how cloud dashboard UIs evolve over time, there are three universal traces you should cross-examine across any database or web API:

Step 1: Cross-Examine the "3 Core Traces"

1. The Gap Between "Request Count" and "Data Transfer (Egress)"

This is the most critical comparison:

• Requests spike, but Egress stays flat: Attackers are hitting your endpoints, but RLS/auth is returning empty arrays []. No data payload is leaving your database.
• Requests spike, and Egress surges proportionally: Real data rows are actively streaming out. This is your immediate red alert.

2. Request Paths and Parameters

Inspect the incoming request logs:

• Are requests targeting internal routes that normal users never navigate to directly?
• Are they appending greedy dump parameters like ?select=* or mass-fetching endpoints?

3. Skewed HTTP Status Codes

Normal organic traffic is overwhelmingly 200 OK.

• 401 Unauthorized
• 403 Forbidden
• 429 Too Many Requests

A rapid burst of 400-level errors in a short window indicates an automated script or vulnerability scanner probing your endpoints for authentication holes.

Step 2: How to Identify "Suspicious Access"

When checking unfamiliar client IPs using lookup tools:

If a data center IP running a Python script is hammering a private API endpoint dozens of times per second, it is almost certainly an automated scanner.

3. Advance Preparation: Automated Alerting

Manually checking dashboard logs every day isn't realistic when building solo. Setting up minimal baseline alerts ensures you get notified before small spikes become disasters:

• Vercel Alert Notifications: Enable threshold alerts in Settings > Notifications (and Spend Management) so you get notified when approaching usage limits or during security events.
• Supabase Billing Email & Over-Quota Alerts: Ensure your organization billing contact is set to an email inbox you actually monitor, so quota limit warnings never go unread.

4. Multi-Layer Defense in Case of a Surge

Here is the defensive hierarchy to keep in mind when traffic spikes occur:

[External Traffic / Scanners]
       │
       ▼
【Layer 1: Vercel WAF】
・Automated bot detection & blocking
・Flip on "Attack Mode" during sustained floods
       │
       ▼
【Layer 2: Supabase RLS】
・Even if requests hit the DB, unprivileged rows return empty []
       │
       ▼
【Layer 3: Spend Cap (Billing Guardrail)】
・Limits API overages to prevent runaway credit card bills

1. Vercel's Attack Mode (The Emergency Brake)

Located under your project's Security (or Firewall) tab:
If you notice sustained malicious scraping, flipping this toggle forces suspected automated traffic to complete a challenge (like CAPTCHA), immediately shutting down automated scripts.

2. Supabase's Spend Cap (The Financial Safety Net)

Under Billing > Cost Control:
Keeping the Spend Cap "Enabled" ensures that if metered limits are ever exceeded, the API gracefully throttles (HTTP 429) rather than racking up runaway cloud bills on your credit card.

5. A Realistic Maintenance Routine for Indie Devs

You don't need to spend hours auditing logs:

• Passive (Day-to-day):
  • If no alert emails arrive from Vercel or Supabase, do nothing. Focus 100% on product features.
• Weekly (Takes 2–3 minutes):
  • Glance at the usage charts for uncharacteristic request/egress spikes.
  • Skim recent API logs to ensure 400-level errors aren't clustering abnormally.

Conclusion

Reading news about "traces of unauthorized access" used to feel either like an abstract corporate problem or a terrifying unknown.

By walking through official documentation and mapping out:

• "Check Egress bytes vs Request counts first, don't panic"
• "RLS protects the payload with empty arrays even under pressure"
• "Set Spend Caps and alert emails to eliminate catastrophic risk"

The fog cleared up significantly, allowing me to focus on actual development.

I hope this practical checklist helps you keep your apps safe and your mind at ease while shipping!

How do you keep tabs on anomalous traffic or potential scrapes in your own stack without dedicated SecOps? I’d love to hear your checklists and monitoring routines in the comments below!

Official Documentation & References

• Supabase: Manage Egress usage
• Supabase: Row Level Security
• Supabase: Spend Cap
• Vercel: Attack Mode