OWASP Top 10: Web Security Vulnerabilities

01What Are OWASP and the Top 10 List?

OWASP (Open Worldwide Application Security Project) is an open community that produces free resources, tools and guides on software security. Its best-known work is the Top 10 list, updated every few years.

The list is not a standard or a certification; it is an awareness document. It is built by combining real-world vulnerability data with expert opinion, and it tells developers to “watch out for these first.” In this article we base our discussion on the categories of the widely accepted 2021 edition.

The list changes over time; in new editions, categories move around or merge. Always check the current edition at the official source, owasp.org.

021–2. Access Control and Cryptography

The first two places on the list are about who data is shown to and how it is protected. Both are among the most common and most severe vulnerabilities, because they touch customer data directly.

Broken access control

An access control failure is when a user can reach data or perform an action they are not authorized for. The classic example: a customer changes order/1052 to 1053 in the address bar and sees someone else's order.

The fix is simple but demands discipline: on every request, on the server side, the question “can this user see this record?” must be asked again. The default behavior should be to deny; access should be opened only where it is explicitly permitted.

Cryptographic failures

Transporting or storing sensitive data without encryption falls under this heading. Storing passwords in plain text or with weak methods, not using HTTPS and outdated encryption algorithms are the most common examples.

For passwords, use slow hashing methods designed for the job, such as bcrypt or Argon2; carry all traffic over HTTPS; and keep encryption keys in a secure environment, not in the code.

033. Injection: SQL Injection and XSS

When data coming from a user is executed as part of a command, it is an injection vulnerability. The best-known types are SQL injection and XSS. In the 2021 list, XSS is also covered under this category.

What is SQL injection?

SQL injection is altering a database query with special characters typed into a form or address field. An attacker can steal or delete data or log in without authorization. The fix is to build the query with prepared statements, not by concatenating strings.

// WRONG: user input is added directly to the query
$sql = "SELECT * FROM uyeler WHERE eposta = '" . $_POST['eposta'] . "'";

// RIGHT: prepared statement
$stmt = $pdo->prepare('SELECT * FROM uyeler WHERE eposta = ?');
$stmt->execute([$_POST['eposta']]);
$uye = $stmt->fetch();

What is XSS?

XSS (Cross-Site Scripting) is the injection of JavaScript written by an attacker into a page. A script entered in a comment field can run in the browser of everyone who opens that page. The basic safeguards are applying context-appropriate escaping when printing output and adding a Content Security Policy (CSP) header.

echo htmlspecialchars($yorum, ENT_QUOTES, 'UTF-8');

044–5. Insecure Design and Misconfiguration

These two categories are less about the code itself than about decisions: how the system is designed and how the server is configured. The good news is that both can largely be prevented with process and checklists.

Insecure design

This category describes a design flaw more than a coding bug. For example, relying only on a guessable security question for password reset, or letting a promo code be tried without limit. Even if the code is flawless, a design hole stays open.

The remedy is to think about security at the start of development, not at the end: threat modeling, abuse scenarios and rate limiting should be discussed at the design stage.

Security misconfiguration

Not changing default passwords, showing server details in error messages, leaving unnecessary services open or leaving directory listing enabled all fall under this heading. These are often the easiest vulnerabilities to exploit.

The fix: prepare a written hardening checklist for the server and the application, turn off error details in production, add security headers (such as HSTS, CSP and X-Content-Type-Options) and audit the configuration regularly.

056–7. Components and Authentication

The risks in sixth and seventh place concern the parts an application takes from outside and the way it verifies who the user is. Both need regular maintenance; setting them up once is not enough.

Vulnerable and outdated components

A modern application uses dozens, even hundreds, of external libraries. When a vulnerability is found in one of them, your application is at risk even if you have not made a single mistake.

The fix: keep a list of the components you use, follow security advisories and update regularly. The audit commands of package managers make this easier. Removing unused dependencies is also one of the cheapest security measures.

npm audit
composer audit

Authentication failures

Allowing weak passwords, being open to unlimited login attempts, storing session IDs insecurely or not ending the session at logout all fall in this category.

The fix: limit the number of attempts, offer two-step verification, check against leaked password lists and configure session cookies with the HttpOnly, Secure and SameSite attributes.

068–10. Integrity, Logging and SSRF

Software and data integrity

Running updates, plugins or an automated deployment pipeline without verification opens the door to an attacker. Signed packages, trusted sources and supply chain auditing are the foundation of the fix.

Logging and monitoring failures

If an attack goes unnoticed, the damage grows. Failed logins, authorization errors and critical actions should be logged, and alerts should be raised in unusual situations. Sensitive data such as passwords must not be written to logs.

SSRF

SSRF (Server-Side Request Forgery) is forcing the server to send a request to an address supplied by the user. This lets an attacker reach services on the internal network. Using an allowlist for the addresses that can be reached is the basic safeguard.

07Secure Coding Checklist

Most vulnerabilities can be prevented with a few basic habits. You can use the list below in code reviews and pre-release checks. We covered how testing ties into security in our post on what software testing is.

1. Never trust input: validate all input on the server side.
2. Use prepared statements: don't build SQL by concatenating strings.
3. Escape output: according to the HTML, URL and JavaScript context.
4. Check authorization on every request: hiding things in the interface is not enough.
5. Keep secrets out of the code: keys belong in environment variables or a vault.
6. Keep dependencies up to date: run an audit command regularly.
7. Log and monitor: notice suspicious events.

08How Safer Languages and Tools Help

Some types of vulnerabilities can also be reduced through the choice of language and tools. For example, memory-safe languages largely prevent the buffer overflow vulnerabilities common in C and C++; we covered this in our post on what Rust is. WebAssembly, which runs in a secure sandbox in the browser, is based on a similar isolation logic.

Still, no language solves an access control or design flaw on its own. In web applications, a large part of security depends on the habits and processes of the team.

At Aurora Yazılım, these basic principles are applied as part of the development process in industry software solutions, corporate website and e-commerce platform projects.