Common Website Security Issues (and How to Prevent Them)

Updated October 2026: revised for the OWASP Top 10:2025, the latest Australian Signals Directorate threat report, and what we see attacking real websites every day.

Most websites that get broken into were found by software, which tries the same handful of weaknesses on millions of sites a day and pays attention to the ones that answer. On a single day in September 2026, our own website’s login page received 14,222 requests. Almost none came from a person.

That is the background for everything below. The common website security issues are common because they are cheap to find, and the fixes are mostly routine work done on time. This guide covers the problems we see most often when we audit or take over Australian websites, and what prevents each one.

What are the most common website security issues?

In order of how often we see them causing real trouble:

1. Outdated software, plugins and third-party code
2. Weak logins and reused passwords
3. Broken access control
4. Security misconfiguration and exposed files
5. Injection, including SQL injection and cross-site scripting
6. Missing, weak or expired encryption
7. Unsafe file uploads
8. No logging or alerting, so nobody notices

The list lines up closely with the OWASP Top 10:2025, the industry’s standard ranking of web application risks. Broken access control sits first in that list, security misconfiguration second, and software supply chain failures, which covers outdated and compromised third-party code, is new at third.

1. Why are outdated plugins and third-party code such a risk?

Because every component on your site is someone else’s code, maintained on someone else’s schedule. A WordPress site with thirty plugins has thirty suppliers, and when one of them publishes a security fix, the vulnerability it fixes becomes public at the same moment. Automated scanners start testing for it within days, sometimes hours.

OWASP’s 2025 list widened this risk into a new category, Software Supply Chain Failures. It now covers more than outdated components: packages that have been taken over by an attacker, abandoned plugins nobody patches any more, and build tools that pull in code without anyone checking it.

How to prevent it:

• Keep an up-to-date list of every plugin, theme, library and external script the site uses.
• Apply security updates on a schedule, weekly for most sites, and immediately for anything flagged as actively exploited.
• Remove plugins you no longer use. A deactivated plugin can still be attacked if its files are on the server.
• Before adding a plugin, check when it was last updated, how many sites use it, and whether its developer has a record of fixing problems quickly.
• For functionality the business depends on, consider building it rather than adding another plugin. We cover the trade-offs in the risks of using plugins in your website.

2. How do attackers get past website logins?

Mostly by using passwords that have already leaked somewhere else. Credential stuffing takes username and password pairs from old breaches and tries them against thousands of sites, on the reasonable bet that people reuse passwords. Brute-force attacks simply guess. Both are automated, constant and cheap to run, which is why a small business login page sees the same traffic as a large one.

How to prevent it:

• Turn on multi-factor authentication for every administrator account. This single change stops the large majority of login attacks.
• Favour long passphrases over short complex passwords, and use a password manager so nobody needs to reuse one.
• Limit login attempts and slow down repeated failures from the same address.
• Remove accounts for people who have left, and review who has administrator access at least twice a year.
• Do not use obvious usernames such as “admin”, and do not publish staff usernames in author pages or feeds.

3. What is broken access control?

It is a site letting someone do or see something they should not. A customer changes a number in a web address and sees another customer’s invoice. A page meant for staff is reachable by anyone who guesses its address. A form that should only update your own profile accepts a request to update someone else’s. Broken access control has topped the OWASP list since 2021, and the 2025 edition folds server-side request forgery into it as well.

It is common because every page and every request has to check who is asking and whether they are allowed, and it only takes one that forgets.

How to prevent it:

• Deny by default. Every page, file and API endpoint should require a deliberate decision to make it public.
• Check permissions on the server for every request, not only by hiding buttons in the interface.
• Use identifiers that cannot be guessed for anything private, such as invoices, documents and customer records.
• Give each user and each system the least access that lets them do their job.
• Test it deliberately: log in as one user and try to reach another user’s data.

4. What counts as security misconfiguration?

Anything left in an unsafe state that would be safe if someone had set it properly. Debug modes switched on in production, directory listings that show every file in a folder, default passwords, sample files left behind by an installer, and configuration files sitting where a browser can download them.

The last one is a favourite target. Bots constantly request files such as /.env, /wp-config.php.bak and private key files, hoping to find database passwords or API keys. On our own servers this month, a large share of that scanning disguised itself as an AI assistant, using the name of a well-known chatbot in its requests to look harmless. The disguise makes no difference if the files are not there to find.

How to prevent it:

• Keep secrets and configuration files outside the public web folder, and never commit them to a code repository.
• Turn off debug output and directory listing on live sites.
• Remove installers, sample files and old backups from the server.
• Set modern security headers. A Content Security Policy limits which scripts can run on your pages. X-Content-Type-Options and a framing policy close off older tricks. The once-recommended X-XSS-Protection header is now obsolete and should be removed or set to 0, since modern browsers have dropped the feature it controlled.
• Review configuration whenever the site moves server or the hosting changes, because that is when settings revert to defaults.

5. Are SQL injection and cross-site scripting still a problem?

Yes, though less than they were. Injection has fallen from first in the 2017 OWASP list to third in 2021 and fifth in 2025, mainly because modern frameworks protect against it by default. The risk now sits in older code, custom code written without those protections, and plugins that build database queries or web pages from user input by hand.

SQL injection lets an attacker change a database query by typing it into a form or a web address, which can expose or delete the whole database. Cross-site scripting (XSS) lets an attacker put their own script into a page that other people then load, which can steal sessions or redirect visitors.

How to prevent it:

• Use parameterised queries for every database call, so user input is always treated as data and never as part of the query.
• Escape output for the context it appears in: HTML, JavaScript, a URL or an attribute each need different handling.
• Validate input on the server. Checks in the browser are a convenience for users, not a security control.
• Set session cookies to HttpOnly and Secure so scripts cannot read them.
• Use a Content Security Policy as a second line of defence.

6. Does my website still need an SSL certificate?

Every page needs HTTPS, and the certificate behind it now needs renewing more often than ever. Since 15 March 2026, publicly trusted certificates can be valid for at most 200 days. That drops to 100 days in March 2027 and 47 days in March 2029. Renewal has to be automatic, and the automation has to be checked, because it fails without telling anyone.

We found two examples of that ourselves this month. An old redirect domain had been serving a certificate that expired more than two years earlier, so visitors saw a browser warning instead of reaching the site it pointed to. Separately, a new client’s staging site had been put behind a password that also blocked the automatic renewal check, and its certificate would have expired weeks later if a review had not caught it. To a visitor, either would have looked like an attack.

How to prevent it:

• Redirect all traffic to HTTPS, and use HTTP Strict Transport Security so browsers never fall back.
• Support TLS 1.2 and 1.3 only. Older versions are no longer safe. We explained why in our guide to the TLS 1.2 upgrade.
• Automate certificate renewal, and monitor expiry dates separately, so a broken renewal is noticed weeks before it matters.
• Check every domain you own, including old ones that only redirect.

7. Why are file uploads dangerous?

Because an upload form lets a stranger put a file on your server. If the site accepts the wrong kind of file, or stores it somewhere the server will run it, an attacker can upload a script and take control of the site.

How to prevent it:

• Accept only the file types the feature needs, and check the file’s actual content, not just its name.
• Rename uploaded files and store them outside the public web folder, or in a folder where the server will never execute anything.
• Set size limits, and scan uploads for malware before anyone opens them.
• Serve private uploads through the application, so access rules apply to every download.

8. How would I know if my website had been attacked?

Often you would not, and that is the problem OWASP’s ninth category describes. A site with no useful logs and no alerts can be compromised for months before anyone notices, usually because a customer or a search engine points it out.

Good logging records the events that matter, such as logins, permission changes, failed access attempts and errors, keeps them somewhere an attacker cannot edit, and has someone or something looking at them. Logs also need reading with care: raw traffic figures are full of automated noise, including bots that pretend to be search engines and AI assistants.

How to prevent it:

• Log authentication events, administrative actions and errors, with accurate timestamps.
• Alert on the few things that should never happen, such as a new administrator account or a login from an unexpected country.
• Keep logs for long enough to investigate an incident, and away from the server they describe.
• Test your backups by restoring one. Until a backup has been restored once, nobody knows whether it works.

Frequently asked questions about website security

What is the most common website security vulnerability?

In the OWASP Top 10:2025, broken access control ranks first, followed by security misconfiguration and software supply chain failures. On small business websites, the problem we meet most often in practice is outdated plugins and themes, followed by administrator accounts without multi-factor authentication.

How often should a website be updated?

Security updates for the platform and plugins should be applied weekly, and urgent fixes as soon as they are released. Review user access every six months, check that backups restore every quarter, and have the site’s security reviewed at least once a year or after any major change.

Do small businesses really get targeted?

Yes, mostly because automated attacks do not distinguish between a small business and a large one. The Australian Signals Directorate’s Annual Cyber Threat Report 2024-25 recorded more than 84,700 cybercrime reports, about one every six minutes. The average self-reported cost to a small business rose 14% to $56,600 per report.

What does a website security breach cost?

The direct costs are investigation, repair and lost trading time, and for businesses that hold personal information, possible obligations under Australia’s Notifiable Data Breaches scheme. The indirect cost is trust, which takes far longer to recover. Routine prevention costs a small fraction of either.

Can I look after website security myself?

Much of it, yes. Multi-factor authentication, password managers, regular updates and removing old accounts need no specialist. Code review, penetration testing, access control design and server hardening do, and they matter most for sites that take payments or hold personal information.

Need a hand with your website’s security?

We build and look after websites and web applications for Australian businesses and agencies, and security is part of every project from the first scoping conversation. Code Brewery is rated Very Strong on the ProcessUnity Risk Index and is an Advanced supplier on the NSW Government ICT Services Scheme.

We can review an existing site, harden it, take over its maintenance, or build something new with these protections in place from the start. For the everyday practices that keep a site out of trouble, see The Boring Security Work That Prevents the Interesting Incident.

Anthony Muscat is the Director of Code Brewery, a Sydney software, app and web development studio that has spent more than two decades building for businesses and agencies across Australia. He makes sure security is part of the plan from the first scoping conversation on every project. Reach out to Anthony to talk through how well your website is protected.