Web Application Security: OWASP Top 10 in Practice - XSS, CSRF, Authentication, and Audit Checklist

Web application security is not an option, but a mandatory requirement at all stages of development. According to OWASP statistics, more than 80% of vulnerabilities are related to code errors, misconfiguration, or architectural shortcomings. In this article, we'll break down the key threats from the OWASP Top 10, focus in detail on XSS, CSRF, and authentication issues, and offer a practical checklist for self-audit. The material will be useful for developers, team leads, and product owners who want to minimize risks and build reliable systems.

OWASP Top 10: What It Is and Why It Matters

The OWASP Top 10 is a global list of the most critical web application security risks, updated every few years. The latest version (2021) reflects the changing threat landscape and includes:

• A01:2021 – Broken Access Control (access control violation)
• A02:2021 – Cryptographic Failures (cryptographic failures)
• A03:2021 – Injection (injections)
• A04:2021 – Insecure Design (insecure design)
• A05:2021 – Security Misconfiguration (security misconfiguration)
• A06:2021 – Vulnerable and Outdated Components (vulnerable and outdated components)
• A07:2021 – Identification and Authentication Failures (identification and authentication failures)
• A08:2021 – Software and Data Integrity Failures (software and data integrity failures)
• A09:2021 – Security Logging and Monitoring Failures (security logging and monitoring failures)
• A10:2021 – Server-Side Request Forgery (SSRF) (server-side request forgery)

Each of these categories requires attention, but it's impossible to cover everything in a single article. Therefore, we will focus on three attack vectors that are most common in code review and security audits: cross-site scripting (XSS), cross-site request forgery (CSRF), and authentication weaknesses. Along the way, we will provide links to web application development services where security is built in at the architecture and code level.

XSS: Types, Vectors, and Practical Protection

XSS (Cross-Site Scripting) remains one of the most common vulnerabilities despite decades of efforts. The essence of the attack is the injection of a malicious script into a web application's response, which then executes in the victim's browser. There are three main types.

Reflected XSS

The attacker sends a script via request parameters, and the server immediately "reflects" it in the response body without proper sanitization. For example, a validation error where a search query is displayed on the page without escaping: http://example.com/search?q=. Mitigation: always escape user input in the context of the output (HTML, JavaScript, URL). Use Content Security Policy (CSP) to restrict script sources.

Stored XSS

The most dangerous type. The script is stored in a database (comment, username) and then displayed to other users without filtering. Everyone who loads the page receives the malicious code. Solution: server-side input sanitization, output encoding, and using frameworks with automatic escaping (React, Angular, Vue). When developing web applications at ESK Solutions, we always implement context-aware escaping and never trust any user field.

DOM-based XSS

The script modifies the DOM via unsafe JavaScript methods (innerHTML, document.write), processing data from the URL or browser storage without validation. Example: document.innerHTML = location.hash.slice(1). Mitigation: avoid dangerous methods in favor of safe APIs (textContent), sanitize data on the client, regularly update dependencies, and scan code with static analyzers.

CSRF: Why a Token Is Not a Silver Bullet

CSRF (Cross-Site Request Forgery) allows an attacker to perform actions on behalf of an authenticated user without their knowledge. The classic scenario: the victim is logged into a banking application, clicks a phishing link, and the browser silently sends a request to transfer money using stored cookies. The main defense is CSRF tokens, generated server-side and bound to the session. However, implementing them requires discipline.

Where tokens are not enough

• Unsafe states: if the token is only checked for POST, but a GET request changes data (e.g., deletion via GET /delete?id=1). All mutating operations should be idempotent and protected.
• Subdomains and CORS: with weak CORS and SameSite Cookie configuration, an attacker can launch an attack from a subdomain. Set SameSite=Strict or Lax, check Origin/Referer headers.
• API endpoints: in SPAs and mobile apps, double-submit cookies or authorization headers are often used instead of tokens. Any API should require explicit confirmation, not rely only on session cookies.

When developing SaaS solutions, we implement multi-layered CSRF protection: custom headers, Origin checks, CSRF tokens with short lifetimes, and binding to a specific action. This is especially important in multi-tenant systems, where a single vulnerability could compromise many clients' data.

Authentication and Sessions: Common Mistakes

Identification and authentication failures (A07) often become the starting point for compromising the entire system. Let's look at the most common oversights.

Weak password policies

Lack of length and complexity requirements, allowing common passwords (check against the Have I Been Pwned database), storing passwords in plaintext or with outdated hashing (MD5, SHA1). Use bcrypt, scrypt, or Argon2 with salt. When developing CRM systems that store personal data and customer history, hashing and password reset policies must be flawless.

Vulnerable password recovery mechanisms

Predictable links, lack of time and attempt limits, secret questions whose answers can be found on social media. The correct approach: send a unique one-time link with a short TTL, multi-factor authentication (MFA) for critical actions.

Improper session management

Session fixation, failure to invalidate the session after privilege escalation (e.g., after entering a second factor), passing tokens in the URL. Always regenerate the session ID upon authentication, use HttpOnly and Secure flags for cookies, and for SPA apps, store JWT in httpOnly cookies, not localStorage. This is especially relevant for corporate intranet portals where employees work with confidential documents.

Web Application Security Audit Checklist

Before going to production, be sure to go through the checklist. It is based on best practices and OWASP recommendations.

• Access control: verify all roles and permissions on the server side; every API endpoint must explicitly check authorization. Avoid "hidden" pages that rely only on lacking links.
• Cryptography: all data transmission — only over TLS 1.2/1.3. Store secrets outside code (secret managers). No custom encryption algorithms.
• Injections: use parameterized database queries (Prepared Statements), ORM without raw SQL. Validate and escape everything that goes into the command line, XML, JSON.
• XSS: implement Content Security Policy in report mode, then enforce. Pass all output fields through contextual escaping. Regularly scan code, e.g., with OWASP ZAP.
• CSRF: ensure all mutating requests (POST/PUT/DELETE) are protected with a token, headers, or SameSite cookies. Check preflight request handling.
• Authentication: MFA for admin panel and critical operations. Lockout after N failed attempts. Store sessions in a secure storage (Redis with password).

The Role of Architecture in Security: What to Establish from Day One

Many vulnerabilities arise from the lack of a well-thought-out security architecture. The "Security by Design" principle means that protection is not bolted on at the last moment but is woven into every component of the system. For example, when designing custom web applications, we define a threat model, separate services by data sensitivity level, and implement a centralized authorization service. This avoids scattered permission checks and reduces the risk of missed restrictions.

In a microservice architecture, it is especially important to monitor inter-service authentication. Use mutual TLS (mTLS) and short-lived tokens with limited scope. For cloud solutions based on AWS, Azure, or GCP, be sure to apply IAM policies with least privilege and audit them regularly.

Multi-tenant systems — SaaS products — deserve special attention. Here, data isolation between tenants should be at the database or application logic level, not just through a tenant_id parameter. Any error in segregation will lead to cross-tenant leakage, which is rated as critical.

Internal tools are equally important. Corporate intranet portals often store payroll sheets, strategic documents, and legally significant records. Security for such systems starts with detailed role-based access (RBAC/ABAC), action auditing, and integration with corporate SSO (LDAP, Azure AD).

Finally, even systems not directly related to finance can become targets. CRM platforms contain customer databases, correspondence, and deal history. Leakage of this data carries reputational and legal risks. Therefore, security auditing should be a continuous process, not a one-time event.

Frequently Asked Questions

How often should a web application security audit be performed?

Basic automated auditing (dependency scanning, SAST/DAST) should be integrated into the CI/CD pipeline and executed with every commit. Manual in-depth audits involving penetration testers should be conducted at least once a year, as well as after significant architectural changes or when adding new critical features.

Is it mandatory to implement MFA for all users?

Ideally, yes, but it may reduce conversion. It is recommended to enforce MFA for administrators, operators, and all roles with access to sensitive data. For regular users, provide the option and encourage its use. At the very least, backup two-factor authentication during password reset should always be implemented.

Which to choose: SameSite cookies or CSRF tokens?

The modern approach is to combine both. SameSite=Lax blocks most CSRF attacks for typical navigation requests, but does not protect against some scenarios on subdomains or complex integrations. CSRF tokens provide more deterministic protection, especially for mutating APIs. The best practice is to use both mechanisms and also check the Origin/Referer headers.

Can automatic security scanners be fully trusted?

No. Scanners miss logical vulnerabilities, business logic issues, and complex exploitation chains. They are the first line of defense but do not replace manual penetration testing and architectural audit. For example, a scanner may not detect that a cumulative discount is applied without authorization checks.

Conclusion

Web application security is a continuous cycle: risk analysis, implementation of protective measures, testing, and monitoring. Understanding XSS, CSRF vectors, and authentication weaknesses allows preventing most incidents. By following the audit checklist and integrating security at every stage—from design to operations—you build trust in the product. If your project requires deep expertise in secure web application development, ESK Solutions specialists are ready to help design and implement a reliable solution taking into account current threats and industry standards.