You opened your app this morning, or got an email from a customer, and your stomach dropped: private data is showing where it shouldn't, charges you did not make are on your Stripe account, or a stranger is sitting in your admin panel. Your instinct is to start frantically deleting things, rewriting code, maybe pulling the whole app down. Stop. The next fifteen minutes matter more than the next fifteen hours, and the most expensive mistakes happen in the first panicked hour, when founders destroy the evidence they need and tip off the attacker while leaving the actual hole wide open. This is the playbook we run, in order, every time a founder calls us mid-incident.
If your Base44 app was compromised, work the steps in order and resist the urge to start editing. First, contain: rotate every secret, revoke all user sessions to log the attacker out, and disable the specific abused feature. Second, assess the blast radius from your logs, not your gut. Third, preserve evidence before you change anything, because remediation overwrites it. Fourth, notify the people you legally owe a notice — GDPR gives you 72 hours from becoming aware. Only then remediate the underlying hole, and finish with a short post-mortem so the same default cannot bite you again. Panic edits destroy the evidence you need and leave the real gap wide open, which is the single most expensive mistake founders make mid-incident.
The First 15 Minutes: Contain Before You Investigate
The single most important decision in any breach is to separate containment from investigation, and to do containment first. Containment means stopping ongoing access without yet understanding the whole story. You do not need to know how the attacker got in to slam the doors they are walking through, and waiting until you fully understand the incident only gives them more time inside your app. Across the 100+ Base44 apps we have shipped or debugged, the founders who came out cleanest contained within the first half hour and investigated afterward.
There are exactly three containment moves, and you can do all three in about fifteen minutes. Rotate every secret the app touches: your Stripe key, your email-sending key, any third-party API tokens. If the attacker copied a key, rotating it makes their copy useless immediately. Revoke all active sessions so every logged-in user, including the attacker, is forced to authenticate again — the fastest way to kick an intruder out without taking the app down. Disable the specific abused feature, whether that is a leaky endpoint, an open upload form, or an admin route, rather than disabling the whole app.
| Move | What it stops | Time | Risk if you skip it |
|---|---|---|---|
| Rotate all secrets | Attacker reusing stolen keys | 5 min | Continued charges, data access |
| Revoke all sessions | Attacker staying logged in | 2 min | Live session keeps reading data |
| Disable the abused feature | The specific exploit path | 5 min | The hole stays open |
| Preserve logs first | Losing the evidence trail | 3 min | You can never prove scope |
Notice what is not on that list: deleting records, rewriting code, or pulling the app offline. Those are remediation and they come later, after you preserve evidence. If you cannot rotate keys quickly or are unsure which feature is abused, that is the moment to get an engineer on a free 15-minute scoping call or request urgent Base44 developer help — containment done wrong is worse than containment delayed.
Assess the Blast Radius: What Did They Actually Reach?
Once the bleeding has stopped, the question shifts from "make it stop" to "how bad is it." This is the assessment phase, and it is where Base44 security incident response either becomes a clean, defensible story or a vague guess you will regret when a regulator or customer asks for specifics. The goal is a concrete answer to one question: which data and which accounts did the attacker touch? You build that answer from logs, not intuition, which is why preserving them during containment matters so much.
On Base44 specifically, the most common compromise is not a sophisticated break-in. It is one logged-in user reaching another user's data because a row-level access rule was left at the AI's permissive default — the exact failure mode in is my Base44 app secure. When that is the cause, your blast radius is how many records crossed an account boundary, so look for one account reading or changing records it does not own. If a key leaked, the blast radius is everything that key could touch: every charge for a Stripe key, every record for a database key.
| Signal to check | What it tells you | Where to look |
|---|---|---|
| Cross-account record access | RLS / access-control breach | Data access logs |
| Logins from new locations | Account takeover | Auth logs |
| Spike in API calls or charges | Automated abuse, leaked key | Provider dashboards |
| New admin users or role changes | Privilege escalation | User/role table |
| Unfamiliar file uploads | Malicious upload path | Storage logs |
Here is the hard truth about assessment: if your app has no logging, you cannot prove a small blast radius, and for notification purposes you must assume the worst plausible scope. "We think it was only a few records" is not defensible; "our logs show exactly these 14 records were accessed" is. This is why monitoring is one of our five security must-haves, and why its absence turns a contained incident into an open-ended liability. Which failure modes leave which traces is mapped in the OWASP Top 10 in Base44.
Preserve the Evidence Before You Touch Anything
This is the step founders skip, and skipping it is the most expensive instinct in a breach. The moment you rewrite the vulnerable code, delete suspicious records, or restore from a backup, you overwrite the evidence that tells you what happened and how far it went. We have walked into incidents where the founder "fixed it" within an hour and then could not answer a single question their customers were legally owed — because the answers had been edited away.
Preservation is simple and fast. Before you change anything, capture the current state: export the relevant logs, screenshot the abused data and any attacker-created records, note the timestamps of what you found and when you found it, and copy the vulnerable code before you patch it. If you are about to restore a database from backup, snapshot the compromised state first so you keep both. Treat it the way you would a crime scene — photograph it before you clean it. This evidence is what lets the lead engineer at Base44Devs reconstruct a timeline and give you a defensible blast-radius statement instead of a shrug.
One specific Base44 trap: the AI builder can silently re-loosen an access rule on a later edit, so the "fix" you apply today can be undone by tomorrow's prompt. Preserve the before-state so you can prove the rule was correct and so a regression is obvious if it recurs. Keep evidence somewhere the app cannot overwrite — a separate folder, not the app's own storage — and document it in plain language with timestamps, because the version of you writing a notification next week will not remember what the panicked version saw today.
Notify the People You Legally Owe a Notice
Once you know what was reached, you have to decide who needs to be told, and this is not optional when customer data is involved. The instinct to quietly fix-and-hide a breach is understandable and it is the single decision most likely to turn a security problem into a legal one. Regulators treat concealment far more harshly than the breach itself, and customers who learn you hid an exposure rarely forgive it. The base44 breach what to do question is, at this stage, mostly a legal and communication question, not a technical one.
The timelines are real and they are short. Under GDPR, if any EU resident's personal data was exposed, you generally must notify the relevant supervisory authority within 72 hours of becoming aware of the breach — which is why your preserved record of when you discovered it matters. Most US states require notifying affected individuals without unreasonable delay, and some sectors (health, finance) carry stricter rules. We are engineers, not lawyers, so the right move when real personal data was reached is to bring in counsel and use your preserved evidence and blast-radius statement to scope the notification accurately.
| Who | When | What they need |
|---|---|---|
| Data protection authority (GDPR) | Within 72h of awareness | Scope, data types, remediation |
| Affected customers | Without unreasonable delay | What was exposed, what to do |
| Payment provider (if cards/charges) | Immediately | The fraud/abuse pattern |
| Your legal counsel | Before customer notice | Everything you preserved |
| Co-founders / team | Now | The plain-language timeline |
The notification you write from preserved evidence is calm and specific: here is what happened, here is exactly what was and was not exposed, here is what we have done, here is what you should do. The notification you write from a guess is vague, alarming, and invites the follow-up questions you cannot answer. Good containment and assessment are what make a notification survivable. If you handle regulated data and are unsure of your duties, raise it on the free scoping call and we will help you nail down the technical facts your lawyer needs.
Remediate the Hole, Then Run a Post-Mortem
Only now — contained, assessed, preserved, and with notification decided — do you fix the underlying vulnerability. The order matters because remediation is the step that destroys evidence, so it has to come after preservation, and because patching the bug does nothing about the access that already happened. Closing the door does not un-ring the bell; it only stops the next visitor. Remediation on Base44 usually means tightening the specific access rule that leaked, moving a leaked secret out of the front end and into a backend function, or adding the input and upload validation that was missing — the structural fixes in our security hardening checklist.
How much this costs depends on the shape of the incident. A clean, single-cause compromise — one loose rule, one leaked key — is squarely a bug-fix sprint at a flat $1,500, delivered in 48 to 72 hours with a money-back guarantee if we cannot resolve it. A messier incident with multiple compromised systems, a full forensic timeline, and broad remediation runs $3,000. Once the fire is out, a standalone $497 audit confirms the hole is actually closed and sweeps the rest of the app for the next one, because a breach almost never travels alone.
| Incident shape | Engagement | Price | Timeline |
|---|---|---|---|
| Single cause, clear scope | Bug-fix sprint | $1,500 | 48-72h |
| Multiple systems / forensic timeline | Complex fix | $3,000 | Scoped per case |
| Post-incident verification | Production audit | $497 | 1 business day |
| Free triage to scope the above | Scoping call | $0 | 15 min |
The last step pays off for years: the post-mortem. Write down, in plain language, the trigger (how they got in), the propagation (what they reached), and the root cause (the decision or default that made it possible), then list the change that prevents a repeat. The point is not blame; it is that the same permissive-RLS or leaked-key failure recurs constantly on Base44 because the AI builder optimizes for "make it work," not "refuse the wrong person." A two-paragraph post-mortem and one hardening change converts a terrifying morning into a one-time event instead of a recurring nightmare.
What to Do Right Now
If you are reading this mid-incident, here is the compressed version: contain in the next fifteen minutes by rotating every key and revoking all sessions, do not delete or rewrite anything yet, preserve your logs and screenshots, then get help to assess the real scope. The worst breaches we clean up are not the ones with clever attackers — they are the ones where a founder, trying to help, edited away the evidence and reopened the hole an hour later.
When you are ready for hands on the problem, the fastest path is urgent Base44 developer help for an active incident, or the free 15-minute scoping call if you need someone to tell you which tier you are in. Most contained incidents resolve inside a $1,500 sprint, and we credit a $497 audit against the fix when a finding turns into a repair. The worst outcome here is not the breach itself; it is a breach handled out of order. Work the playbook, preserve the evidence, and tell the people you owe a notice. Everything after that is fixable.
Related reading
- Is My Base44 App Secure? — the five things that, when missing, cause most of these incidents.
- OWASP Top 10 in Base44 — the standard risk list mapped to real Base44 failure modes.
- Base44 Security Hardening Checklist — the remediation companion: how to close the hole after an incident.