Quick answer: The OWASP Top 10 is a widely used awareness document that lists the ten most critical security risks for web applications. The current edition, published in 2017, covers injection, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, cross-site scripting, insecure deserialization, using components with known vulnerabilities, and insufficient logging and monitoring. It is not a full security standard, but it is a good baseline: if your site or app handles logins, payments or customer data, your developers should be able to explain how they address each item.
What OWASP is
OWASP, the Open Web Application Security Project, is a nonprofit community that produces free tools, guides and research on software security. Its best known output is the Top 10, which has been updated every few years since 2003. The 2017 list replaced the 2013 edition and is the version most teams use today.
The list is built from data contributed by security firms and from a community survey. It ranks risks by how common they are, how easy they are to exploit and how much damage they cause. That makes it a practical starting point rather than an academic one.
Business owners do not need to understand every technical detail. But knowing the list helps you ask better questions when you hire developers, review a quote or approve a launch.
The OWASP Top 10 (2017), explained
A1: Injection
Injection happens when an application sends untrusted input to an interpreter, such as a database, as part of a command. The classic example is SQL injection, where a form field is crafted so the database runs the attacker’s query instead of the intended one. That can expose or delete entire tables.
What prevents it: parameterized queries (prepared statements), using a well maintained data access layer, and validating input on the server. In WordPress, that means using $wpdb->prepare() rather than building queries from raw strings.
A2: Broken authentication
This covers weaknesses in login and session handling: allowing weak passwords, no protection against password guessing, session IDs exposed in URLs, sessions that never expire, or poor password reset flows.
What prevents it: rate limiting and lockouts on login, two-factor authentication for admin accounts, secure session cookies, and checking new passwords against lists of known breached passwords.
A3: Sensitive data exposure
Applications sometimes store or send personal or financial data without proper protection. Examples include passwords stored in plain text or with weak hashing, data sent over plain HTTP, or backups left in public folders.
What prevents it: HTTPS everywhere (see our guide to moving a site to HTTPS), strong password hashing, encrypting sensitive data at rest, and not storing data you do not need. If you take cards, let a payment provider handle the card data.
A4: XML external entities (XXE)
Older or badly configured XML parsers can be tricked into reading files from the server or making network requests when they process a malicious XML document. This matters for applications that accept XML uploads or older SOAP integrations.
What prevents it: disabling external entity processing in XML parsers, preferring simpler formats like JSON where possible, and keeping parser libraries updated.
A5: Broken access control
Access control decides what each user is allowed to do. When it fails, a regular user can view another customer’s order by changing an ID in the URL, or reach admin functions they should not see.
What prevents it: checking permissions on the server for every request, denying by default, and testing with different user roles. This is one of the most common flaws in custom portals, which is why it should be a standard item in any code audit.
A6: Security misconfiguration
This is the broadest category: default admin accounts left active, directory listing turned on, verbose error messages showing stack traces, unused features enabled, missing security headers, or cloud storage buckets left open to the public.
What prevents it: a repeatable, documented server setup, removing defaults, turning off debugging in production, and reviewing configuration after every change. Managed hosting helps, but it does not cover your application settings.
A7: Cross-site scripting (XSS)
XSS happens when an application includes untrusted data in a page without proper escaping, letting an attacker run JavaScript in other users’ browsers. That script can steal sessions, change page content or trick users into actions.
What prevents it: escaping output based on context (HTML, attributes, JavaScript, URLs), using templating systems that escape by default, and adding a Content Security Policy. WordPress provides functions like esc_html() and esc_url() for exactly this.
A8: Insecure deserialization
Some applications turn stored or transmitted data back into objects. If an attacker can tamper with that data, they may be able to run code or change application behaviour. PHP object injection is one well known form.
What prevents it: not accepting serialized objects from untrusted sources, using simple data formats like JSON, and signing data that must travel between systems.
A9: Using components with known vulnerabilities
Modern sites depend on frameworks, libraries, plugins and themes. When one of those has a published vulnerability and you do not update, attackers can use automated tools to find and exploit it at scale. For WordPress sites, outdated plugins are the most common way in.
What prevents it: an inventory of the components you use, regular updates, removing unused plugins, and monitoring vulnerability announcements. A routine maintenance plan covers most of this.
A10: Insufficient logging and monitoring
Many breaches go undetected for months because nobody is watching. Without logs of logins, failed access attempts and admin changes, you cannot spot an attack in progress or investigate one afterwards.
What prevents it: logging security relevant events, keeping logs somewhere an attacker cannot easily erase, setting alerts for suspicious patterns, and having someone responsible for reviewing them.
How the 2017 list changed from 2013
Three new categories were added in 2017: XML external entities, insecure deserialization, and insufficient logging and monitoring. To make room, some older items were merged or dropped: insecure direct object references and missing function level access control were combined into broken access control, and cross-site request forgery and unvalidated redirects fell off the list, partly because modern frameworks now handle them better by default.
That does not mean CSRF is no longer a risk. It means it is less common in new applications. The Top 10 is a list of the most critical risks, not the only ones.
What the Top 10 is and is not
It is an awareness document, a shared vocabulary between developers, testers and business owners, and a sensible minimum for any web application.
It is not a complete security standard or a compliance certificate. For deeper verification, OWASP publishes the Application Security Verification Standard (ASVS), and regulated businesses may have their own requirements such as PCI DSS for card data.
Treat a claim like “we are OWASP Top 10 compliant” with care. Ask how each item was checked.
Questions to ask your developer or agency
- How do you prevent SQL injection and XSS in the code you write?
- How are passwords stored, and do admin accounts use two-factor authentication?
- How do you check that one customer cannot see another customer’s data?
- Which third-party libraries and plugins does the site use, and who updates them?
- Is debugging turned off in production, and are default accounts removed?
- What security events are logged, and who would notice an attack?
- Do you run a security test before launch, and can I see the results?
Good teams will answer these comfortably. Vague answers are a warning sign, especially for custom applications or sites that handle payments. If you build integrations that exchange data with other systems, our guide to API security covers related risks.
FAQ
Does the OWASP Top 10 apply to WordPress sites?
Yes. WordPress core is well maintained, but plugins, themes and custom code can contain any of these flaws. Outdated components (A9) and broken access control in custom features are the most common issues.
How often is the list updated?
Roughly every three to four years. The 2017 edition is current, and OWASP collects data between editions for the next update.
Is a security plugin enough?
A security plugin helps with login protection, monitoring and some misconfiguration checks. It cannot fix insecure custom code or flawed access control. You still need secure development and regular updates.
Who should run a security test?
For simple brochure sites, regular updates and a security plugin go a long way. For portals, stores and custom applications, an independent test before launch and after major changes is worth the cost.
Build security in from the start
Most of the Top 10 is cheaper to prevent during development than to fix after a breach. If you are planning a site or application that handles logins, orders or customer records, make these risks part of the brief and the acceptance checklist. If you want a build where security is part of the plan rather than an afterthought, see how we approach projects on our Turn visitors into customers page.
