How Do Business Websites Get Hacked, and What Should You Fix First?

How do business websites actually get hacked? Far more often through a missed update, a password stolen somewhere else, a backup left in a public folder or a script nobody reviewed than through an attack designed for one company. Here are the six usual paths, the owner's list and the developer's list, what the work takes in hours, and what to do in the first hour after a breach. This is a guide for defenders: it covers what to close and leaves out how to break in.

IN SHORT

How websites really get hacked

Most business websites are hacked through ordinary gaps: outdated plugins and frameworks, stolen admin passwords, careless file upload, files and backups left in public folders, third-party scripts and accounts nobody closed. Close them in this order: access first, then backups and updates, then exposed files and uploads, then scripts. For a typical site that is about 30 to 75 hours of work by our estimate, followed by a monthly routine.

Verizon's 2026 Data Breach Investigations Report covers more than 22,000 confirmed breaches in 145 countries, from October 2024 to November 2025. Exploiting a software flaw is now the most common way in, at 31% of breaches, ahead of phishing at 16% and credential abuse at 13%. In North America the split is 30%, 12% and 20%, so stolen logins weigh more for US companies. Among small and medium businesses a third party was involved in 55% of breaches. These figures cover every kind of breach, websites included, so read them as a direction rather than as a website statistic.

The direction is useful, because a flaw that is mass-exploited within hours of being published cannot be aimed at anyone in particular. Whoever runs that software is on the list.

Nobody has to choose your company for your site to be attacked.

SIX PATHS

Six paths and what closes them

These six cover most of what we check when a site comes to us:

OWASP's Top 10 for 2025 sees web applications from the code side and agrees on the shape of the problem: broken access control is first, security misconfiguration second, software supply chain failures third. OWASP reports some form of the first two in 100% of the applications tested. Access control often passes every visual check: the interface hides a button, while the server would still carry out the request if it arrived. OWASP's rule is "deny by default", enforced in server-side code.

No scanner can check these rules for you, since who may see which order or invoice is your business logic. That is one more reason to build a system around how the company really works, with roles written down before screens. QA and software testing then checks them with a real account for each role. A product put together quickly with AI tools is the usual weak spot here. Our MVP review, from $3,000, says what to keep, fix or rebuild, and You Built an MVP With AI. Keep It, Fix It or Rebuild It? explains how we decide.

OUTDATED CODE

Updates and support calendars

Plugins are where the numbers are best documented. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024: 91% in plugins, 9% in themes and only 6 in WordPress core. Its weighted median time to first exploitation of heavily exploited flaws was 5 hours, and 46% of vulnerabilities had no fix from the developer when they were disclosed. In its tests, traditional hosting defences blocked 12% of WordPress-specific attacks using known exploited flaws. Patchstack sells protection against exactly this, so weigh that last figure accordingly. WordPress itself comes out well; the exposure lies in how many plugins a site carries and who still maintains them.

Two practical conclusions follow. Removing a plugin you do not use closes a risk that an update may not, since nearly half of the flaws arrive with no fix available. OWASP's advice is the same: remove unused dependencies and watch for components that are no longer maintained. And plan for speed honestly: Verizon found that only 26% of the flaws on CISA's list of vulnerabilities known to be exploited were fully fixed in 2025, with a median of 43 days, up from 32 a year earlier. The datasets differ, so the gap between 43 days and 5 hours is an illustration, not a measurement.

For custom systems the same work is planned around public support calendars. As of November 2026:

The dates will age; the habit lasts. Put these dates in a calendar a year ahead, run each upgrade on a closed copy, and release it in an hour when customers are least active, ending with a real test lead, not just a page that opens. Upgrading an Old Laravel or PHP Site in 2026 walks through it, including a site whose owner had no visible reason to worry: PHP 5.6 on the server, a hosting account controlled by someone outside the business, service scripts open to the public, and PHP errors that could be shown to visitors. A controlled move fixed it in two evenings.

When a site is several versions behind, the price depends on neglect more than on distance: The Hidden Technical Debt That Makes Website Redesigns More Expensive Than Planned explains why. That case starts with a website modernization audit, from $300 for small sites and from $1,000 for large ones.

ACCESS

Passwords and forgotten accounts

The clearest public example of password risk is the 2024 campaign against customers of Snowflake, a cloud data platform. Mandiant found no evidence that Snowflake's own environment was breached; about 165 potentially exposed organizations were notified. The accounts had no multi-factor authentication, at least 79.7% had credentials exposed earlier, and some of those credentials came from infections dating back to November 2020 and had never been changed.

NIST's current guidance, SP 800-63B-4, has moved far from the rules many companies still enforce. Passwords used alone must be at least 15 characters. Composition rules and forced periodic changes are out, except when there is evidence of compromise, and new passwords must be checked against lists of breached ones. It also states plainly that passwords are not phishing-resistant, so a hardware key or passkey is the better second factor for the accounts that matter most.

Turn on two-step sign-in in this order, because each account can reset or replace the next:

1. Domain registrar. Whoever holds the domain can point your site and your email anywhere.
2. Main business email. Password resets for everything else land here.
3. Hosting and server access. This reaches the code, the database and the backups.
4. Code repository and deployment. A change here ships to production.
5. Site admin, payment and tag manager accounts. A tag manager can place a script on every page, checkout included.

Abandoned accounts are the same risk with a longer fuse: a business can have strong controls and still have former contractors holding active server credentials that nobody revoked. Keep one list of who can reach what and whose name each account is in. Give people the narrowest role that lets them work, so a content manager has no access to user management. Disable departing users rather than deleting them, so the history stays readable. A section holding leads or customer data can sit behind a second login of its own.

Keep passwords and API keys in environment files or a secret store, outside the code. Laravel's documentation is direct about it: an .env file should not go into source control. If a key has already landed there, GitHub's first step is the right one for any host: revoke or rotate it, and only then think about cleaning history. Changing a contractor means changing those keys the same day, as described in Taking Over a Website or App From Another Developer.

FILES AND UPLOADS

Uploads and forgotten files

OWASP's testing guide describes how exposed files work: a renamed or backup copy of a file tends to be served as plain text, not executed, which exposes server-side code and credentials. A database dump in a public folder needs no hacking at all. Keep rollback copies, dumps and logs outside anything the web server can serve, and avoid editing files directly on production, since editors leave temporary copies behind.

You can run a basic check on your own site, and only there. Request your-site/.env and your-site/.git/config. A 403 or a 404 is what you want. A 200 with your normal "page not found" design is a false alarm, which OWASP's guide warns about. If the file itself opens, close it now and treat every password inside as stolen. Also confirm that debug mode is off on production. Laravel warns that with APP_DEBUG on, you risk showing sensitive configuration values to visitors, and OWASP lists detailed error messages among common misconfigurations.

For file upload, OWASP's checklist is short:

• allow only the file types the business needs, from a list, and block nothing by exception;
• check the real type of the file, because the type the browser declares can be faked;
• give each file a new name generated by the application;
• store uploads on a separate host or outside the web root, with the narrowest permissions;
• set a size limit and let only authorized users upload.

A file manager built into an admin panel falls under the same rules: changes only through its own interface, only for signed-in staff with the right role.

Test copies are the other forgotten files. A staging site on a hidden address with a full copy of the live database is a second, less protected copy of your customers. A test copy should be closed at the server level, use anonymized data with no real leads, and be deleted after acceptance.

SCRIPTS

Scripts you did not write

Every tag on your site runs with the same rights as your own code. Verizon puts third-party involvement at 48% of all breaches in the 2026 report, up 60% from the year before, and at 68% in retail.

Every script on your checkout can read what your customer types.

Two cases show how this looks from the owner's chair. In February 2024 a new owner bought the domain and GitHub account of Polyfill, a popular JavaScript library. In June, Sansec reported malware injected into more than 100,000 sites that loaded it. The code activated only on certain mobile devices at certain hours and skipped admin users, so an owner checking the site from an office computer saw nothing wrong. Earlier, in the 2018 British Airways case, traffic was diverted to a fraudulent site, card details of about 429,612 customers and staff were taken, and the breach went unnoticed for more than two months. The UK regulator's fine was £20 million, and it named multi-factor authentication for staff and third-party accounts among the measures that could have helped.

For anyone taking cards, this has been a formal requirement since 31 March 2025. PCI DSS requirement 6.4.3 says each script on a payment page must be authorized, its integrity assured, and all of them listed in an inventory with a written reason. Requirement 11.6.1 adds a mechanism that alerts staff to unauthorized changes in the page and its HTTP headers as the browser receives them.

Many stores embed a provider's form in an iframe and assume this no longer concerns them. PCI SSC did remove both requirements from the SAQ A questionnaire, but added a condition: the merchant confirms its site is not susceptible to attacks from scripts. That can be shown with techniques like those in 6.4.3 and 11.6.1, or with written confirmation from a compliant payment provider. Ask your acquirer how to validate this, since PCI SSC does not enforce the standard itself.

Cards or no cards, the work is the same: list every script, including those added through the tag manager; remove what nobody can explain; keep payment pages close to empty. Subresource Integrity lets the browser refuse an external file whose content no longer matches its hash, which works for fixed versions of a library. Content Security Policy tells the browser which scripts may load, and it can start in report-only mode, so nothing breaks while you learn what your pages use.

TWO LISTS

The owner's list and the developer's

An owner can find most of the risk without reading code. Put these questions to your team or contractor; by our estimate the answers take about half a day to collect:

• Are the domain, the hosting and the main mailbox in the company's name, and can you sign in to them today?
• Is two-step sign-in on for each of them?
• Who can reach production right now, by name, and when was that list last checked?
• Which versions of PHP, the framework or the CMS run the site, and when does their security support end?
• When was a backup last restored, how long did it take and what was missing? Untested Backups and Growing Cloud Bills explains the test.
• Which scripts run on checkout or lead forms, and who approved them?
• Who is responsible for an incident, what response time is written down, and who are your lawyer and your payment provider's contact?

The developer's list turns those answers into work. The hours below are our planning estimates for one business site on a supported or nearly supported version. They are a guide, not a quote, and an upgrade across several versions is a project of its own.

That adds up to 30 to 74 hours. The order matters more than the total: access and backups come first because they limit the damage of anything still open while the rest gets done.

FIRST HOUR

The first hour after a breach

This sequence keeps your options open; it is not legal advice. Its core comes from the FTC's guide for businesses.

1. Name one person in charge and start a written log with times. Who noticed what, and when. Bring in your developer, then a lawyer, and a forensic specialist if customer or card data may be involved.
2. Do not wipe anything and do not restore yet. The FTC's wording is "do not destroy evidence", and it advises taking affected equipment offline without turning machines off until forensic experts arrive. Ask the host to preserve server logs, since logs get rotated.
3. Contain. Put the site or the affected part into maintenance mode. If a checkout may be skimming cards, switch off payments first.
4. Change credentials from a clean device. Hosting, database, admin, mail, payment and API keys, and end all active sessions. As the FTC notes, stolen logins keep working after the attacker's tools are removed.
5. Find the way in before you put the site back. A clean backup restored over an open hole can be reinfected, so the fix goes on with the restore.
6. Check your deadlines with your lawyer. All 50 states have breach notification laws, and they differ. Washington, for example, gives 30 calendar days to notify consumers, and requires notice to the attorney general when more than 500 residents are affected. If you sell to people in the EU, GDPR Article 33 sets 72 hours for notifying the regulator, where feasible. If cards are involved, call your payment provider.

Once the site is clean, open the Security Issues report in Google Search Console, because hacked pages can carry a warning in search results and in browsers. Fix every listed issue on every affected page, then use Request Review and describe what you did. Google says reviews for malware take a few days and reviews for sites hacked with spam can take up to several weeks.

WHO DOES IT

Who keeps it closed

None of this stays done: new flaws appear, people leave, marketing adds tags. Our website maintenance and support covers that routine: framework, PHP and package updates, security patches, daily off-site backups with restore tests, monitoring, and a monthly report, from $1,000 a month, with response times fixed in your plan. Access, secrets, servers and release pipelines are a job for DevOps and cloud engineers, at $50 to $70 an hour, and role checks before large releases for QA, from $30 an hour. If the people who built the site are gone, start with a project takeover audit, from $2,500. All prices are on the pricing page.

We keep an inventory of domains, hosting and accounts with a note on whose name each one is in, and the code, deployment commands and documentation are handed over to you under the contract. A system you can leave is also safer, because its access is written down. When a product needs a formal penetration test or a compliance assessment, that is a separate specialist job, and we say so.

Access you can list is access you can close.

FAQ

Sources

• Verizon: 2026 Data Breach Investigations Report, executive summary
• OWASP Top 10:2025
• Patchstack: State of WordPress Security in 2026
• Mandiant, Google Cloud: UNC5537 targets Snowflake customer instances
• Sansec: Polyfill supply chain attack