Common Website Security Vulnerabilities and How to Prevent Them

Most website breaches do not involve sophisticated, targeted hackers.

They exploit a small number of well-known weaknesses: an outdated plugin, a login page with no protection against password guessing, a form that passes user input straight into a database, a page that shows one customer's data to another, or a cloud storage bucket left open to the internet. Automated tools scan the web constantly for exactly these problems, so any site that has them will eventually be found.

The good news is that the same short list of vulnerabilities accounts for a large share of real-world incidents, and each has well-established defences. The OWASP Top 10, a widely used awareness document produced by the Open Worldwide Application Security Project, summarises the most critical web application security risks and is a sensible place to start. Its 2021 edition placed broken access control first, followed by cryptographic failures, injection, insecure design and security misconfiguration. OWASP has been working on an updated edition, so check the latest version.

This guide explains the most common website security vulnerabilities in plain language: what each one is, how attackers exploit it, real incidents that show the impact, and the practical steps that prevent it. It finishes with how to build layered defences and what to do if something does go wrong. It is written for business owners, managers and developers who want a clear picture rather than a technical manual.

Why websites get attacked

Many small business owners assume their website is too small or unimportant to be a target. In practice, most attacks are not personal. Criminals use automated tools to scan millions of sites for known vulnerabilities, then exploit whatever they find. A small site with an unpatched plugin is just as attractive to an automated scanner as a large one.

Attackers want different things from different sites. Some want data: customer details, payment information, login credentials or confidential business documents. Some want money directly, through ransomware or by injecting code that skims card details from checkout pages. Others want resources: a compromised server can send spam, host phishing pages, mine cryptocurrency or join a botnet that attacks other targets. Some simply deface sites or redirect visitors to scams. Search engines may then flag the site as dangerous, damaging traffic and reputation.

The scale of the problem is significant. The UK government's Cyber Security Breaches Survey 2025 found that 43 percent of UK businesses reported a cyber security breach or attack in the previous twelve months, with the proportion considerably higher among medium and large businesses. Verizon's annual Data Breach Investigations Report has found that exploiting vulnerabilities and using stolen credentials are among the most common ways attackers gain initial access to organisations, with vulnerability exploitation rising in recent editions.

The consequences go beyond the immediate disruption. A breach can mean investigation and recovery costs, lost sales, regulatory penalties under data protection law, notification obligations to affected customers and lasting damage to trust. For many small businesses, preventing the most common vulnerabilities is far cheaper than dealing with even one incident.

Broken access control

Access control decides who can see and do what. Broken access control means users can reach data or functions they should not, and OWASP ranked it the most serious web application risk in its 2021 Top 10, reporting that some form of it was found in the large majority of applications it tested.

How it happens

A common example is changing a number in a web address. If a customer viewing their invoice at a URL ending in "invoice=1045" can change it to "invoice=1046" and see someone else's invoice, the application is checking that the user is logged in, but not that the invoice belongs to them. Security professionals call this an insecure direct object reference. Similar problems occur when admin pages are hidden from menus but not actually protected, when users can change their own role or permissions by altering a request, or when an API returns more data than the user interface displays.

These flaws are particularly dangerous because they often look like normal use. An attacker does not need special tools, only a browser and curiosity, and automated scripts can enumerate thousands of records quickly.

How to prevent it

Check permissions on the server for every request, not just in the user interface. Hiding a button is not a security control. Deny access by default and grant it explicitly, so that new pages and functions are protected unless someone deliberately makes them public. Verify that the logged-in user owns or is allowed to access each specific record they request, rather than trusting identifiers supplied in the URL or form.

Use your framework's established authorisation features instead of writing custom checks scattered throughout the code. Apply the principle of least privilege to user roles and to staff accounts in content management systems, giving each person only the access they need. Log access-control failures and alert on unusual patterns, such as one account requesting large numbers of records in sequence. Include access-control checks in code reviews and security testing, because automated scanners often miss them.

Injection attacks: SQL injection and cross-site scripting

Injection vulnerabilities occur when a website treats data supplied by a user as if it were instructions. Two forms are especially common on websites.

SQL injection

Most websites store data in a database and use a language called SQL to query it. If a site builds database queries by inserting user input directly into the query text, an attacker can enter specially crafted input that changes what the query does, for example retrieving every customer record, bypassing a login or deleting data.

SQL injection has been understood for decades, yet it still causes major incidents. In 2023, a SQL injection vulnerability in MOVEit Transfer, a widely used file transfer product, was exploited by a criminal group in a mass data theft campaign that affected a very large number of organisations worldwide, including government agencies, universities and businesses, many of which had never heard of the attackers.

The main defence is to use parameterised queries, also called prepared statements, or a well-maintained database library or ORM that uses them. These keep the query structure fixed and treat user input strictly as data. Validate input against what you expect, for example numbers where numbers are required, and give the database account used by the website only the permissions it needs.

Cross-site scripting (XSS)

Cross-site scripting occurs when a site includes user-supplied content in a page without handling it safely, allowing an attacker to inject scripts that run in other visitors' browsers. A malicious comment, profile field or search term could steal session cookies, capture keystrokes, redirect users or alter what they see. OWASP's 2021 Top 10 grouped XSS under injection.

The key defence is output encoding: making sure content from users is displayed as text rather than interpreted as code, in the right way for where it appears on the page. Modern front-end frameworks such as React, Angular and Vue encode output by default, but developers can bypass these protections with certain features, which should be used only with great care. A Content Security Policy, an HTTP header that tells browsers which scripts are allowed to run, adds a strong second layer of protection. Marking session cookies as HttpOnly prevents scripts from reading them.

Other forms of injection

The same principle applies to other systems that interpret text as commands, such as operating system commands, LDAP directories and email headers. More recently, applications that pass user input to large language models face prompt injection, where crafted input manipulates the model's behaviour. The common rule is never to mix untrusted input with instructions without a safe separation.

Weak authentication and session handling

Login pages are among the most frequently attacked parts of any website. If attackers can sign in as a customer, an employee or an administrator, they often do not need any other vulnerability.

Common weaknesses

Credential stuffing uses usernames and passwords leaked from other breaches, relying on people reusing the same password across sites. Because billions of credentials have been exposed over the years, automated tools can try enormous numbers of combinations quickly. Brute-force and password-spraying attacks try common passwords against many accounts. Weak password rules, default administrator accounts left unchanged and no limit on login attempts all make these attacks easier.

Session handling matters too. After login, a website usually issues a session token, typically stored in a cookie. If tokens are predictable, never expire, are not invalidated on logout or are sent over unencrypted connections, an attacker who obtains one can impersonate the user.

Password reset processes are another frequent weak point. Reset links that never expire, security questions with guessable answers and reset emails that reveal whether an account exists can all be exploited.

How to prevent it

Offer and encourage multi-factor authentication for users, and require it for administrators and staff. Passkeys, which are supported by major browsers and operating systems, offer strong, phishing-resistant authentication and are increasingly practical for consumer sites.

Follow modern password guidance, such as the US National Institute of Standards and Technology's SP 800-63B, which favours longer passwords, checks against lists of known compromised passwords and discourages forced periodic changes and arbitrary complexity rules. Store passwords using a slow, salted hashing algorithm designed for the purpose, such as Argon2, bcrypt or scrypt, never in plain text or with fast general-purpose hashes.

Limit login attempts with rate limiting, temporary lockouts or challenges after repeated failures, and monitor for unusual login activity. Generate session tokens using your framework's secure defaults, set cookies with the Secure, HttpOnly and SameSite attributes, expire sessions after inactivity and invalidate them on logout and password change. Make reset links single-use and short-lived, and avoid revealing whether an email address is registered.

For administrator areas, consider additional controls such as restricting access by IP address, using a separate admin domain or placing admin panels behind a VPN or zero-trust access service.

Outdated software, plugins and supply chain risks

Modern websites are built from many components: a content management system or framework, plugins and themes, open-source libraries, third-party scripts for analytics, chat or payments, and the server software underneath. Each component can contain vulnerabilities, and each one you do not control is a potential way in.

Unpatched components

When a vulnerability is discovered and fixed, the details often become public, and attackers quickly begin scanning for sites that have not applied the update. The 2017 Equifax breach is a well-known example. Attackers exploited a vulnerability in Apache Struts, a web application framework, for which a patch had already been released, and went on to access personal information on around 147 million people. In late 2021, the Log4Shell vulnerability in the widely used Log4j logging library showed how a flaw in a single common component can expose vast numbers of systems at once.

For sites built on content management systems, plugins are a particular concern. Security firms that track WordPress vulnerabilities, such as Patchstack and Wordfence, consistently report that the large majority of newly disclosed WordPress vulnerabilities are in plugins and themes rather than in WordPress core. Abandoned plugins that no longer receive updates are especially risky.

Third-party scripts and supply chain attacks

Scripts loaded from other domains run with the same power as your own code. In 2018, attackers modified a script on British Airways' website to send customers' payment details to a site they controlled, a type of attack often called Magecart or digital skimming. The UK Information Commissioner's Office later fined the airline £20 million. In 2024, the domain behind polyfill.io, a library loaded by a very large number of websites, changed hands and began serving malicious code to some visitors, affecting sites that had simply included a link to it years earlier.

How to prevent it

Keep an inventory of the software, plugins, libraries and third-party scripts your site uses. Apply security updates promptly, prioritising those rated critical or known to be actively exploited; the US Cybersecurity and Infrastructure Security Agency maintains a Known Exploited Vulnerabilities catalogue that helps with prioritisation. Remove plugins, themes and libraries you no longer use, and replace those that are no longer maintained.

Use dependency scanning tools, such as those built into GitHub, GitLab and many CI pipelines, to alert you to vulnerable libraries. Limit third-party scripts to those you genuinely need, load critical scripts from trusted sources, use Subresource Integrity where practical so browsers reject altered files, and use a Content Security Policy to restrict where scripts can load from. For payment pages, keep third-party scripts to an absolute minimum; PCI DSS version 4 introduced specific requirements for managing scripts on payment pages.

Security misconfiguration and exposed data

Many breaches involve no clever exploit at all. Something was simply left open, switched on or set up with insecure defaults.

Common misconfigurations

Typical examples include default or shared administrator passwords, detailed error messages that reveal software versions, file paths or database details, directory listings that let anyone browse files on the server, admin panels and development tools exposed to the internet, unused services and ports left running, and backup files, configuration files or database dumps stored in publicly accessible locations.

Cloud services add their own risks. Storage buckets, databases and search clusters have been exposed to the internet many times through incorrect permission settings, sometimes revealing millions of records. API keys and passwords accidentally committed to public code repositories are another frequent source of compromise.

Weak encryption and missing security headers

OWASP's 2021 Top 10 placed cryptographic failures second. On websites, the most basic requirement is HTTPS everywhere, with certificates kept current and older, insecure protocol versions disabled. HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for your site, preventing downgrade attacks. Sensitive data should also be encrypted at rest in databases and backups.

Security headers provide additional protection with little effort. Beyond Content Security Policy and HSTS, headers that prevent your site from being embedded in frames on other sites, stop browsers from guessing content types and limit what information is sent in referrer headers all reduce common risks. Free tools can check which headers a site sends.

How to prevent it

Use a documented, hardened baseline configuration for servers, frameworks and cloud services, ideally defined in code so it can be reviewed and reapplied consistently. Change all default credentials, disable features and services you do not need, and turn off detailed error messages in production while logging the details privately. Restrict admin interfaces to authorised users and networks. Keep secrets such as API keys and passwords in a proper secrets manager rather than in code. Use cloud provider tools that detect publicly exposed storage and insecure settings, and review configurations regularly, especially after changes.

Other vulnerabilities worth knowing

Several other weaknesses appear regularly in security assessments and incidents. They are less famous than SQL injection but just as important to understand.

Insecure file uploads

Any feature that lets users upload files, such as CVs, profile images or documents, can be abused to upload malicious files. If an uploaded script can be executed on the server, the attacker may take control of the site. Restrict allowed file types by checking content as well as file extensions, rename uploaded files, store them outside the web root or in separate cloud storage, scan them for malware and limit file sizes.

Cross-site request forgery

Cross-site request forgery (CSRF) tricks a logged-in user's browser into sending an unwanted request to your site, such as changing an email address or making a transfer, from another site the user visits. Modern frameworks include CSRF protection through unique tokens on forms, and setting the SameSite attribute on cookies adds further protection. Make sure these defences are enabled rather than switched off for convenience.

Server-side request forgery

Server-side request forgery (SSRF), added to the OWASP Top 10 in 2021, occurs when an application fetches a URL supplied by a user, such as an image link or webhook address, without proper checks. Attackers can use it to make the server request internal resources that should never be reachable from outside, including cloud metadata services that may hold credentials. Validate and restrict destinations, block requests to internal addresses and use cloud provider protections for metadata services.

Insecure design

Some vulnerabilities are not coding mistakes but design flaws, such as a password reset process that relies on easily discovered information, a checkout that trusts prices sent from the browser or a discount system that can be applied repeatedly. OWASP introduced insecure design as a category in 2021 to highlight the value of threat modelling: thinking through how features could be abused before building them.

Insufficient logging and monitoring

Many breaches go unnoticed for weeks or months because no one is watching. Without logs of logins, access-control failures, administrative actions and errors, it is hard to detect an attack or investigate one afterwards. Log security-relevant events, protect logs from tampering, keep them for an appropriate period and set alerts for suspicious activity.

Denial of service and bots

Automated traffic can overwhelm a site, scrape content, attempt credential stuffing or abuse forms. Content delivery networks and web application firewalls with bot management, rate limiting and DDoS protection reduce the impact, and CAPTCHA-style challenges can protect forms that attract abuse.

Building layered defences and a prevention routine

No single control prevents every attack. Effective website security relies on several layers, so that if one fails, others still protect the site and its data. Security professionals often call this defence in depth.

The layers

At the edge, a content delivery network and web application firewall (WAF) filter malicious traffic, block common attack patterns, absorb denial-of-service attacks and manage bots. A WAF is a useful extra layer, but it cannot fix vulnerabilities in your code, so treat it as a safety net rather than a cure.

In the application, secure coding practices prevent vulnerabilities from being introduced in the first place: parameterised queries, output encoding, server-side access checks, secure session handling and input validation. Use well-maintained frameworks and keep them updated.

At the level of identity, multi-factor authentication, strong password handling, least-privilege roles and careful management of administrator accounts limit what an attacker can do with stolen credentials.

For data, encryption in transit and at rest, minimal data collection and well-protected backups reduce the impact if something is breached. Data you do not hold cannot be stolen.

In the infrastructure, hardened server and cloud configurations, prompt patching and secrets management close the gaps attackers look for.

Across everything, monitoring and response let you detect and contain problems quickly.

A practical routine

For most organisations, a sustainable routine matters more than occasional large projects. Apply security updates for the CMS, plugins, frameworks and servers on a regular schedule, with critical updates applied as soon as possible. Run automated vulnerability and dependency scans, ideally as part of the development pipeline, so problems are caught before release. Review user accounts and permissions periodically, removing people who no longer need access. Test backups by restoring them, not just by checking that they ran. Commission a penetration test from qualified testers before launching significant new functionality and periodically afterwards, particularly for sites that handle payments or sensitive data. Train staff to recognise phishing, because stolen staff credentials often lead to website compromises. And use recognised frameworks, such as the OWASP Application Security Verification Standard or the UK's Cyber Essentials scheme, to check that the basics are covered.

Responding when something goes wrong

Even well-protected sites can be compromised. The difference between a contained incident and a disaster often comes down to how quickly it is spotted and how calmly it is handled.

Recognise the signs

Common signs of a compromised website include unexpected changes to pages, new administrator accounts you did not create, redirects to unfamiliar sites, warnings from Google Search Console or browsers that the site is unsafe, a sudden spike in traffic or outgoing email, unexplained files on the server, alerts from your hosting provider or security plugin, and customers reporting suspicious messages or payment problems.

Contain, investigate, recover

If you suspect a compromise, act quickly but carefully. First, contain the problem: take the site offline or into maintenance mode if necessary, revoke suspicious accounts, reset passwords and API keys, and block malicious traffic. Preserve evidence such as logs and copies of affected files before cleaning anything, because they help you understand what happened and may be needed for regulators, insurers or law enforcement.

Next, investigate how the attacker got in and what they accessed. Restoring a backup without fixing the original weakness often leads to reinfection within days. Then recover by restoring from a known clean backup or rebuilding, applying updates and fixes, and monitoring closely for any return of malicious activity. If your site was flagged by Google, request a review in Search Console once it is clean.

Meet your obligations

If personal data may have been accessed, data protection law may require you to act within strict time limits. Under the UK GDPR and EU GDPR, certain personal data breaches must be reported to the relevant supervisory authority, such as the Information Commissioner's Office in the UK, within 72 hours of becoming aware of them, and affected individuals must be told without undue delay where there is a high risk to them. If card data may be involved, notify your payment provider. Check your cyber insurance policy, which may require prompt notification and may provide access to incident response specialists. In the US, state breach notification laws set their own requirements.

Learn from it

Once the immediate crisis is over, review what happened, why it was not prevented or detected sooner and what will change. Document an incident response plan in advance, including who to contact and how to reach your hosting provider, developers and advisers out of hours, so you are not working this out under pressure.

For many organisations, the hardest part of website security is not knowing what to do but finding the time and expertise to do it consistently. An experienced cloud and security partner can assess your site against common vulnerabilities, set up monitoring, patching and backups, harden hosting and cloud configurations, and help you prepare an incident response plan, while keeping your team informed and in control.