How to Protect Your Business Web App From Data Breaches

To protect your business web app from data breaches, get five things right: strict access control on the server, strong login with multi-factor authentication, fast patching of the software you depend on, locked-down configuration and secrets, and logging that tells you when something is wrong. No single tool covers all five. Most of the work is ordinary engineering, not exotic security research.

This guide is for founders and product owners who run a live web app or SaaS product. We pulled the latest figures from IBM, Verizon and OWASP, added CISA's small-business guidance, and mapped them to how we build and maintain apps at Bracket Coder. Where a number comes from a report, we name the report. Where it is our own judgement, we say so.

How much does a data breach cost a business?

IBM's 2025 Cost of a Data Breach report puts the global average cost of a breach at USD 4.44 million, down 9% from USD 4.88 million the year before. It also reports that the mean time to identify and contain a breach fell to 241 days, the lowest in nine years. Even in a good year, that is roughly eight months before a typical breach is under control.

• USD 4.44Mglobal average breach cost (IBM, 2025)
• 241 daysmean time to identify and contain (IBM, 2025)
• 31%of breaches began with a vulnerability exploit (Verizon DBIR, 2026)
• 48%of breaches involved a third party (Verizon DBIR, 2026)

Why the average is not your number

These figures are averages across the organisations studied, and large enterprises pull them up. Do not expect your own bill to match. But the shape of the cost is the same at any size: incident response, downtime, engineer time, customer notification, possible regulatory action, and the customers who quietly leave. The lever you control is time. The longer an attacker is inside undetected, the bigger every one of those lines gets.

Shadow AI is now part of the bill

IBM also found that shadow AI, meaning staff using unapproved AI tools, added roughly USD 670,000 to the average breach cost. Among organisations that reported an AI-related security incident, 97% lacked proper AI access controls. If your team pastes customer data into tools you have not vetted, that data has left your control.

How do attackers actually get into business web apps?

Verizon's 2026 Data Breach Investigations Report, released on 19 May 2026, gives the best recent picture. Three findings matter most for web app owners.

Unpatched software is now the most common way in

Verizon reports that exploiting a vulnerability was how 31% of breaches began. It is the first time in 19 years that this has overtaken stolen credentials as the top entry point. Verizon also says AI has compressed the time between a flaw becoming known and attackers using it, from months to hours. A web app is a stack of other people's code: framework, libraries, web server, database, operating system. Every layer has its own patch stream, and attackers watch all of them.

Stolen and weak logins still matter

Credentials lost the top spot, not their danger. CISA's small-business resources list four essentials: avoid phishing, use a password manager for strong passwords, turn on multi-factor authentication (MFA), and keep software updated. CISA specifically urges phishing-resistant MFA. In practice that means passkeys or hardware security keys, which are stronger than one-time codes typed into a page, because codes can be phished.

Your vendors and tools are part of your attack surface

Verizon says third-party involvement rose 60% and now features in 48% of breaches. It also reports that unapproved AI tool use among employees tripled, to 45%. Payment providers, analytics scripts, open-source packages, plugins and AI agents connected to your accounts all count. We covered the agent side in our look at Meta Muse sharing a user's address, and the design rules in what to automate vs keep human.

What is the OWASP Top 10, and what does it mean for your app?

OWASP, the Open Worldwide Application Security Project, is a non-profit that publishes a ranked list of the most serious web application security risks. Developers and auditors widely use it as a baseline. The current edition is the OWASP Top 10:2025. Here it is in plain English, with the default defence we apply. The plain-English column is our own reading, not OWASP's wording.

OWASP 2025 risk	What it means in plain English	Our default defence
A01 Broken Access Control	A user can see or change data that is not theirs	Server-side permission checks on every request, deny by default
A02 Security Misconfiguration	Debug mode left on, default passwords, open storage	Hardened per-environment settings and automated config checks
A03 Software Supply Chain Failures	A vulnerable or tampered library, plugin or build tool	Lockfiles, dependency scanning, fewer packages
A04 Cryptographic Failures	Sensitive data unencrypted or weakly protected	TLS everywhere, encryption at rest, modern password hashing
A05 Injection	Untrusted input runs as a query or script	ORM or parameterised queries, output escaping
A06 Insecure Design	A feature built without thinking about abuse	Threat-model risky features before building them
A07 Authentication Failures	Weak login, no MFA, guessable resets	MFA or passkeys, rate limiting, safe reset flows
A08 Software or Data Integrity Failures	Trusting updates, plugins or data without verifying them	Reviewed, pipeline-only deploys and verified artefacts
A09 Security Logging and Alerting Failures	An attack happens and nobody sees it	Central logs and alerts on suspicious events
A10 Mishandling of Exceptional Conditions	The app fails unsafely when something unexpected happens	Fail closed, safe error messages, tested failure paths

The first item deserves the most attention. OWASP's guidance for Broken Access Control is to deny by default for anything that is not a public resource, and to build access control once and reuse it everywhere instead of re-implementing it page by page.

How do you protect a web app from data breaches? An 8-step plan

Security works in layers. A login screen, a permission check, encrypted data and an alert each stop a different kind of failure, so when one layer slips, another catches it. The eight steps below are the order we would tackle them on a live app.

Step 1: Enforce access control on the server, for every request

Access control means the server decides, on every request, whether this user may see or change this record. The classic failure is changing an ID in a URL and seeing another customer's data. Multi-tenant SaaS is especially exposed: every query must be scoped to the tenant, not just the pages that look sensitive. Run the two-account test on your own app:

1. Create two users in different organisations.
2. As user A, copy the URL or API call for one of A's records.
3. Log in as user B and replay it.
4. Anything other than a refusal is a breach waiting to happen.

Then turn it into an automated test so it runs on every release.

Step 2: Harden login and sessions

Require MFA for staff and admin accounts first, then offer it to customers. Prefer passkeys or hardware keys where you can, since CISA urges phishing-resistant MFA. Rate-limit login and password-reset endpoints, check new passwords against known-breached lists, use your framework's password hasher instead of your own, set cookies as secure and HTTP-only, and expire sessions sensibly. Keep the admin panel off the public internet, or behind a VPN or IP allow-list, if you can.

Step 3: Patch and pin dependencies

Commit lockfiles so builds are repeatable, run automated dependency scans in your pipeline, and remove packages you no longer use. Then set a patch clock. Our rule of thumb: critical fixes in days, not weeks, and routine updates on a fixed weekly or fortnightly slot. Verizon's finding that exploitation now leads the way in is the reason. This is the unglamorous core of application maintenance and support.

If attackers can exploit a flaw within hours, your patch process cannot run on a quarterly calendar.

Step 4: Lock down configuration and secrets

Misconfiguration is number two on OWASP's list because it is so easy to do. Turn debug mode off in production, restrict allowed hosts, force HTTPS and send security headers. Keep API keys and database passwords out of your code repository, in environment variables or a secrets manager, and rotate any that were ever committed. Give each service the minimum cloud permissions it needs, and keep the database off the public internet. For Django apps, the official deployment checklist covers the main settings.

Step 5: Protect the data itself

Collect less: data you never store cannot leak. Encrypt in transit with TLS and at rest with database or disk encryption, and consider field-level encryption for the most sensitive fields. Set retention rules so old data is deleted. Keep automated backups in a separate account or location, and test a restore. A backup that has never been restored is a hope, not a plan. Do not copy production data onto laptops or into staging without masking it.

Step 6: Treat all input as hostile

Injection is still on the OWASP list. Use your ORM or parameterised queries instead of building SQL from strings, escape output in templates, validate file uploads by type and size, and validate on the server even when the front end already checks. Add rate limits to public API endpoints so abuse shows up as a spike you can see.

Step 7: Log, monitor and alert

Remember IBM's 241 days. You shorten that number by seeing things. Log sign-ins, failed permission checks, admin actions, data exports and configuration changes. Send logs somewhere an attacker on the server cannot edit them. Alert on patterns: a burst of failed logins, an admin login from a new country, one account exporting thousands of records. OWASP lists logging and alerting failures as a top-ten risk for exactly this reason.

Step 8: Manage vendors, integrations and AI tools

Keep a list of every third-party service that touches customer data. Give each API key the narrowest scope possible, and remove access when a contract ends. Publish an approved list of AI tools so staff have a safe option rather than a private one. Never let an agent send or share data without a human approval step enforced in code.

Do framework defaults make an app safe?

They help a lot, but they do not finish the job. Django, which we use for many of our backends, ships several protections switched on in a new project: the ORM builds parameterised queries, templates escape output to block cross-site scripting, CSRF middleware guards form posts, and passwords are stored as salted hashes rather than plain text.

What no framework gives you is your business rules: who may see which invoice, and which tenant owns which record. That logic is yours, and it is where Broken Access Control lives. We compare the trade-offs in Django vs Node.js for SaaS, and cover the auth and CORS pitfalls of a split front end in Next.js with a Django REST API.

What does it cost to secure a web app, and where should the money go?

There is no honest single price, because it depends on how much code you have and what shape it is in. The table shows the effort ranges we typically estimate for a mid-sized existing app. Treat them as planning ranges, not a quote; a real number needs a look at your code.

Control	Typical effort (our estimate)	Main risk it reduces
Permission audit plus automated access tests	2 to 5 days	Broken access control
MFA for staff and admins, optional for customers	1 to 3 days	Account takeover
Dependency scanning and an update routine	1 to 2 days to set up, then ongoing	Exploited known vulnerabilities
Secrets and configuration review	1 to 2 days	Leaked keys, misconfiguration
Backups plus a tested restore	1 to 2 days	Data loss, ransomware recovery
Central logging and alerts	2 to 4 days	Slow detection

Start with the rows that match your biggest exposure. If you hold customer data for many tenants, begin with access control. If you have a public admin panel, begin with MFA. See our pricing page for how we scope this kind of work.

What should you do in the first 72 hours after a suspected breach?

Write this plan before you need it. If you handle personal data about people in the EU, GDPR generally expects you to notify the regulator within 72 hours of becoming aware of a breach that puts people at risk, and other laws set their own clocks. Ask a lawyer which apply to you. This is not legal advice.

1. Contain. Revoke suspect sessions and API keys, disable compromised accounts, and isolate affected servers.
2. Preserve evidence. Snapshot servers and export logs before you rebuild anything.
3. Scope. Work out what was accessed, for how long, and whose data it was. This is where good logging pays for itself.
4. Notify. Tell your legal contact, your insurer if you have one, affected customers and regulators as required, in plain language.
5. Fix and learn. Close the hole, rotate every secret that may have been exposed, and write a short post-mortem listing the changes you will make.

If you inherit an app that is already in this state, the sequence we use is in how to take over and stabilize an existing web application.

A 30-day plan to harden a live web app

You do not need a six-month programme to get the basics right. This is the order we would work through in a month.

Week	Focus	What to finish
Week 1	Inventory and quick wins	List every admin account, service and secret; turn on MFA for staff; rotate exposed keys; confirm backups exist
Week 2	Access and login	Permission audit, two-account tests in CI, login rate limits, session and cookie settings
Week 3	Patching and configuration	Dependency scan, patch critical items, production settings review, HTTPS and security headers
Week 4	Detection and response	Central logs, alerts, a written incident runbook, and a restore drill from backup

When should you bring in outside help?

Bring in an engineer for a review if any of these are true: you inherited the code and nobody knows what is in it; there are no tests and no logs; you are about to take payments or handle health or financial data; an enterprise customer has sent you a security questionnaire; or your framework version no longer receives fixes. We do this as part of web application development and ongoing maintenance, and for subscription products through our SaaS development work. More guides live in our Security and DevOps hub.

Frequently asked questions

What is the most common way web apps get breached?

According to Verizon's 2026 report, exploiting a known vulnerability is now the most common way in, at 31% of breaches. Stolen credentials and third-party access also feature heavily. That is why patching, MFA and vendor control are all on the plan.

How much does a data breach cost a small business?

There is no reliable single figure. IBM's global average of USD 4.44 million covers the organisations it studied, and large companies skew it upward. A small business should expect the same kinds of cost, including response work, downtime, notification and lost customers, at a smaller scale.

Is HTTPS enough to protect my web app?

No. HTTPS encrypts data in transit so others cannot read it on the network. It does not check who is allowed to see a record, patch a vulnerable library, or stop a stolen password. Treat it as a baseline, not a defence.

Are small businesses really targeted?

Much attack traffic is automated. Scanners look for known flaws on any exposed app, regardless of the owner's size. CISA publishes dedicated resources for small and medium-sized businesses for this reason.

How often should a web app be security tested?

Our practice: run automated dependency and configuration scans on every release, do a manual review of access control and login at least once a year and after major features, and commission a deeper penetration test before a big launch or an enterprise deal.

Is it safe to use AI tools with customer data?

Only through tools you have approved and understood. IBM found shadow AI added about USD 670,000 to the average breach cost, and Verizon reports unapproved AI use is rising. Publish an approved list, restrict what data may be pasted in, and check the vendor's data terms.

Planning to secure or rebuild a web app? Get a free scope and quote and we will tell you where the biggest gaps are and what it takes to close them. You can also see all our services.

Sources

• IBM X-Force: 2025 Cost of a Data Breach Report
• Verizon: 2026 Data Breach Investigations Report findings
• OWASP Top 10:2025
• CISA: Small and Medium-Sized Business Resources
• Django documentation: Deployment checklist