Web Security: OWASP Top 10 and a Pragmatic Checklist for Teams

According to the OWASP Top 10, the most important measures for secure web applications are manageable: check permissions on the server with every request, validate inputs and parameterize queries, secure sessions and passwords properly, harden the configuration, keep dependencies up to date and log security-relevant events. Vulnerabilities rarely result from exotic attacks but from familiar patterns – a missing authorization check, an unfiltered input, an outdated library.

This article shows how to use the OWASP Top 10 as a guardrail, which basics every web project needs and how to proceed with a prioritized checklist – without having to launch a major security project right away.

What the OWASP Top 10 is – and what it isn’t

The Open Worldwide Application Security Project (OWASP) is a nonprofit community that publishes freely available guides to application security. Its best-known publication is the OWASP Top 10: an overview of the most critical risk categories for web applications, revised at intervals of several years. You can see which edition is current at owasp.org – the categories change only in nuances from one edition to the next. Since 2021, Broken Access Control has been at the top; injection, misconfiguration and vulnerable components are perennial issues.

Important: the Top 10 is not a complete testing standard but a guide to which topics must not be missing from any project. If you want to test systematically, turn to the OWASP Application Security Verification Standard (ASVS), which organizes requirements into three levels, and to the OWASP Cheat Sheets with concrete implementation advice. If you build in AI features, they bring risks of their own – OWASP maintains separate lists for them.

Basics before penetration testing

Not every project needs a penetration test right away. But every project needs solid basics: secure sessions, CSRF protection, input validation, secure HTTP headers and regular updates of dependencies. A pentest on an application without that foundation mainly finds problems that standard measures would have prevented – and you still pay for the testers’ time. A pentest becomes worthwhile before sensitive applications go live and after major changes.

The key risk areas – and what helps against them

Access control

A classic example: in a customer portal, a logged-in user changes the invoice number in the address bar – and suddenly sees another customer’s invoice. The solution: every request is checked on the server to see whether the user is allowed to view or change exactly this data. This applies to functions as well, because an admin menu that is merely hidden in the frontend remains reachable via the URL. The basic rule is “deny by default”; permissions are granted selectively. It’s easy to test: use two accounts with different roles and try to retrieve each other’s data.

Miscon­figura­tion

Debug mode enabled on the live system, default passwords, verbose error messages with technical details, publicly accessible cloud storage or admin interfaces reachable from the internet: many vulnerabilities arise not in the code but in the configuration. Hardened default configurations that are versioned and rolled out automatically help – the same level then applies on development, test and live systems, and deviations stand out.

Injection and cross-site scripting

If inputs reach database queries or system commands unchecked, attackers can inject their own commands. Parameterized queries, a properly used ORM and server-side validation of all inputs close this door. With cross-site scripting (XSS), foreign script code is injected into your page and executed in other users’ browsers. Modern frameworks escape output by default – it becomes dangerous where developers deliberately bypass this protection. The same goes for server-side requests, such as an image import by URL: allow only approved targets, otherwise the server can be abused to query internal systems.

Authentica­tion and sessions

Session cookies should be set with the HttpOnly, Secure and SameSite attributes, renewed after login and invalidated on the server at logout. Passwords never belong in the database in plain text but hashed with a method designed for the purpose, such as Argon2id or bcrypt; allow long passphrases instead of complicated character rules and reject known compromised passwords. In addition, CSRF tokens for forms, rate limiting for login attempts and – for sensitive applications and administrators – two-factor authentication should be standard. Passkeys are a modern, phishing-resistant alternative.

Cryptography and secrets

Use current TLS versions (at least TLS 1.2, preferably 1.3) and encrypt sensitive data at rest as well. Credentials and keys never belong in the code repository but in a secrets management system; a scan in the pipeline finds accidentally committed keys before others do.

Dependencies and supply chain

Modern applications consist largely of third-party libraries. Automated scans in the build pipeline report known vulnerabilities, fixed version pins make builds traceable, and a regular update rhythm prevents legacy issues from piling up. As Log4Shell showed at the end of 2021, a single library can affect thousands of applications: if you maintain a bill of materials for your components (SBOM), you quickly know whether you are affected.

Logging and monitoring

Attacks that nobody notices can continue for a long time. Security-relevant events such as failed logins or permission changes should be logged centrally, protected against tampering and monitored – without writing passwords or other sensitive data to the logs. Tested backups belong here too: a backup whose restoration has never been rehearsed is a hope, not a measure, when things go wrong.

Secure HTTP headers: tightening the CSP step by step

HTTP headers are an inexpensive lever with a big effect. These belong on every production site:

Header	Effect	Note
Strict-Transport-Security	enforces HTTPS in the browser	enable only once all subdomains support HTTPS
Content-Security-Policy	limits where scripts, images and frames may be loaded from; second line of defense against XSS	start in report-only mode
X-Content-Type-Options	prevents misinterpretation of file types (nosniff)	serve file types correctly
Referrer-Policy	limits which URL information is passed on to other sites	choose a restrictive value, such as strict-origin-when-cross-origin
Permissions-Policy	disables browser features such as camera or location for the page	enable only what is needed
frame-ancestors (in the CSP)	protects against embedding in other sites (clickjacking)	replaces the older X-Frame-Options

The Content Security Policy (CSP) is the most powerful but also the most demanding header. We introduce it step by step: first in pure report-only mode (Content-Security-Policy-Report-Only) to see which scripts and sources are actually used, then with increasingly strict rules – preferably with nonces rather than blanket-allowed inline scripts. That way the CSP protects without silently blocking functionality. Afterwards, verify the headers with an online scanner or the browser’s developer tools.

Threat modeling and prioritiza­tion: finding risks in a structured way

We clarify which threats are really relevant for your application in a structured threat modeling workshop, which typically lasts two to four hours. Four guiding questions provide the framework: What are we building? What can go wrong? What are we doing about it? Did we look closely enough? The result is a prioritized list of measures that goes straight into the backlog. Besides developers, people from the business department and operations should attend, because they know the processes and data that deserve particular protection.

Practical example: a wholesaler’s customer portal

A wholesaler runs a portal where dealers view orders, prices and invoices. The workshop shows that the biggest risks are not the exotic ones. Invoice numbers appear in the URLs, an old admin frontend is reachable from the internet with a default login, a library for PDF generation hasn’t been updated for years, and failed logins aren’t recorded. The following assessment is an example of prioritization:

Measure	Effort	Impact	Timing
Object-level authorization checks for invoices and orders	medium	high	immediately
Secure admin access: remove default login, 2FA, restrict access	low	high	immediately
Update dependencies, add a scan to the pipeline	medium	high	short term
Set security headers, start the CSP in report-only mode	low	medium	short term
Log login events, set up alerts	medium	medium	next expansion step
Penetration test for verification	high	high	after implementation, before major changes go live

Security in the development process and toward customers

One-off audits go stale quickly. Lasting web security emerges when it is a fixed part of everyday development:

• Definition of done: Security-relevant points such as authorization checks and input validation are part of every acceptance.
• Code reviews: Changes to login, permissions or payment flows are reviewed with particular care.
• Automated checks: Dependency scans and static analysis run on every build in the CI/CD pipeline.
• Regular maintenance: Updates are scheduled at fixed intervals instead of only when something is urgent.

In B2B business especially, customers often demand evidence of security – frequently in the form of extensive questionnaires on access control, encryption, updates, backups and logging. The pressure is growing: the NIS2 Directive obliges certain companies to also consider the security of their supply chain – as a supplier, you can therefore be affected indirectly. We map the OWASP requirements onto your specific architecture and plan from the outset which evidence will be needed for audits or customer questionnaires. That saves time and discussion later. Data protection questions are closely related; our article GDPR and tracking is a good starting point.

The pragmatic checklist for your team

Basics for every web project

• Check permissions on the server with every request
• Validate inputs on the server, parameterize queries
• Escape outputs appropriately for their context
• Enable secure session cookies and CSRF protection
• Hash passwords with Argon2id or bcrypt, use rate limiting for logins
• Enforce HTTPS and set security headers
• Scan dependencies automatically and update them regularly
• Rule out debug mode and default logins on the live system, keep secrets out of the repository

Extended for sensitive applications

• Two-factor authentication for users and administrators
• Start the CSP in report-only mode and tighten it step by step
• Log and monitor security events, restore backups regularly as a test
• Threat modeling workshop before major extensions
• Provide a contact address for security reports (security.txt)
• Penetration test before going live or after major changes

How Nano Concepts can help

Web security doesn’t have to be a major project. If you use the OWASP Top 10 as a guardrail, implement the basics consistently and prioritize risks in a structured way, you close many typical gaps before they become a problem. For WordPress websites, additional rules apply, which we have summarized in the article securing WordPress.

Would you like to know where the security of your web application stands? With our web security service area, we support you from the initial assessment to implementation; regular updates and monitoring can be scheduled firmly through maintenance & support. The initial consultation is free.