How to Fix the Top 5 Web App Vulnerabilities

With all the innovation in digital technologies, web applications are often a significant part of an organization's assets. At the same time, web applications’ attack surface technologies are often a prime target for adversaries and an initial entry point for further attacks on the organization, and in various supply chain attacks. 

Let’s take the example of Log4Shell (CVE-2021-44228), which impacted millions of systems worldwide, including primary cloud services, enterprise software, and web applications. The vulnerability allowed attackers to target web applications that logged user-controlled input, such as form fields, HTTP headers, or API requests, and use it to gain system access. 

Dynamic applications handling user data are connected to databases in the backend, and adversaries often try to target the application in a way that could expose the database, leading to data breaches and exposure. Increasingly, security is shifting left in the software development lifecycle, and developers are essential to the security of web applications. 

In this blog post, we will provide actionable insights into detecting, fixing, and preventing five of the most common web application vulnerabilities. Cobalt pentesting identified over 34,000 web application vulnerabilities in 2024, and these were the top five by percentage of the total number of web vulnerabilities, according to the Cobalt State of Pentesting Report: 

1. Server security misconfigurations (28.4%)
2. Missing access control (19.2%)
3. Cross-site scripting (XSS) (9.4%)
4. Sensitive data exposure (8.1%)
5. Authentication and session (8.0%)
   
   

Let’s understand the impact of vulnerabilities on the organization, its users, and stakeholders. We can also discuss how developers and security teams can work on early detection and implement controls through practices like external attack surface management, source code reviews, penetration testing, and vulnerability management.

Understanding and remediating server security misconfigurations

Most organizations rely on third-party systems or applications at some point in their development life cycle. Server security misconfigurations are the most common vulnerabilities identified. This occurs when security settings in servers are improperly implemented or left at default, leading to vulnerabilities. These misconfiguration vulnerabilities can manifest in various forms, such as:

1. Default credentials: Using factory-default or weak credentials (e.g., "admin/admin") that attackers can easily guess or find online.
   Impact: Unauthorized users can gain full administrative access to systems, which can lead to data theft, compromise, or service disruption.
   Classification: CWE-521: Weak Password Requirements
   Example: CVE-2018-1160: Default credentials in HPE System Management
   
   
2. Exposed admin interfaces: Administrative portals are publicly accessible without proper access restrictions or protections.
   Impact: Attackers can brute force credentials, exploit vulnerabilities, or directly access critical system controls.
   Classification: CWE-306: Missing Authentication for Critical Function
   Example: CVE-2020-1938: Exposed AJP connector in Apache Tomcat
   
   
3. Overly permissive file/directory permissions: Sensitive files or directories have permissions allowing unauthorized users to read, write, or execute them.
   Impact: Attackers can access, modify, or delete critical data, leading to information leakage, privilege escalation, or system instability.
   Classification: CWE-276: Incorrect Default Permissions
   Example: CVE-2018-12895: Overly permissive permissions in Microsoft SQL Server
   
   
4. Unpatched software and outdated dependencies: Running software with known vulnerabilities due to outdated versions or missing patches.
   Impact: Exploitable vulnerabilities can lead to remote code execution, data breaches, or privilege escalation.
   Classification: CWE-937: Use of Known Vulnerable Component
   Example: CVE-2021-44228: Log4Shell vulnerability in Apache Log4j
   
   
5. Unrestricted access to cloud storage: Cloud storage buckets (e.g., S3) are publicly accessible or misconfigured, allowing unauthorized data access.
   Impact: Sensitive information, such as user data or credentials, can be stolen or tampered with.
   Classification: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
   Example: CVE-2020-17384: Misconfigured S3 bucket exposing sensitive Microsoft data
   
   

While oversights can be minor and insignificant, they can significantly impact an organization’s security, including unauthorized access to systems, potential data breaches, system compromises, and significant operational disruptions.

Remediation approaches for developers

Developers play a crucial role in preventing security misconfigurations. They can mitigate potential vulnerabilities by adhering to secure coding practices and implementing robust security measures during development. Some of the measures include: 

1. Avoid default and hardcoded credentials: Change default passwords, rotate regularly, and never hardcode secrets. Additionally, use environment variables or secure vaults for storage.
2. Restrict admin interface access: Limit admin interfaces to trusted IPs, VPNs, or authentication gateways. If exposure is necessary, MFA and strong password policies should be enforced.
3. Enforce least privilege permission: Restrict access to sensitive files, logs, and backups. Apply the least privilege principle and use security tools like SELinux or ACLs.
4. Keep software and dependencies updated: Regularly update OS, web servers, databases, and dependencies. Automate vulnerability detection with Dependabot or OWASP Dependency-Check.
5. Limit sensitive data exposure: Display generic error messages while securely logging detailed errors. Remove sensitive data from logs and turn off debugging in production.
6. Strengthen authentication and authorization: Use strong password hashing (bcrypt, Argon2), enforce MFA, and implement RBAC to limit user access based on necessity.

Understanding and mitigating missing access controls

Access control vulnerabilities occur when the application fails to enforce the principle of least privileges and proper restrictions on authenticated users, allowing unauthorized users to perform sensitive operations or access restricted resources. There could be multiple reasons behind access control vulnerabilities, such as insufficient validation of user roles or permissions in APIs, user interfaces, direct object references and others. Some examples of access control vulnerabilities are as follows:

1. Insecure direct object references (IDOR): A user can directly access objects (e.g., files and records) by manipulating references (such as file IDs) without proper permission checks.I
   Impact: Leads to unauthorized access to sensitive data or system resources.
   Classification: CWE-639: Authorization Bypass Through User-Controlled Key
   Example: CVE-2018-3760: GitLab IDOR exposing sensitive data
   
   
2. Unprotected APIs: APIs that lack authentication or enforce weak authorization checks. 
   Impact: Attackers can exploit exposed endpoints to retrieve or modify critical data.
   Classification: CWE-306: Missing Authentication for Critical Function
   Example: CVE-2021-22986: BIG-IP API vulnerability.
   
   
3. Privilege escalation: Users with low-level permissions exploit flaws to gain higher-level access (e.g., admin).
   Impact: Attackers can manipulate critical system configurations or data.
   Classification: CWE-269: Improper Privilege Management
   Example: CVE-2021-24086:  Windows privilege escalation.
   
   
4. Bypassing function-level access controls: Users manipulate URLs, HTTP methods, or parameters to access restricted functions.
   Impact: Leads to unauthorized execution of privileged actions.
   Classification: CWE-285: Improper Authorization
   Example: CVE-2020-15504:  SolarWinds function-level access vulnerability.
   
   
5. Misconfigured cloud storage access: Publicly accessible cloud resources lack access control, exposing sensitive data.
   Impact: Attackers can retrieve or tamper with confidential data.
   Classification: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
   Example: CVE-2020-17384: Misconfigured S3 buckets exposing Microsoft data
   

Remediation approaches for developers

Developers play an essential role in preventing access control vulnerabilities. A developer can use the following best practices: 

• Principle of least privilege: Define user roles and permissions explicitly, restricting access based on the principle of least privilege.
• Validate user permissions: Ensure all API endpoints require authentication and validate user permissions before executing actions.
• Use a consistent access control framework: Use a single, well-tested framework for access control to avoid inconsistencies across the application.
• Sanitize and validate inputs: Sanitize and validate inputs for operations like ID references to prevent IDOR vulnerabilities.
• Perform routine code reviews and pentesting: Conduct testing to identify and resolve missing access control issues.
• Use MFA: Enhance user authentication by requiring a second verification step.

Understanding and mitigating cross-site scripting

JavaScript is a core component that introduces dynamic behavior in web applications. This puts the web applications at a greater risk for malicious JavaScript code execution, posing significant risks such as XSS attacks.

XSS is a client-side injection attack where malicious scripts are injected into trusted websites or applications. These scripts run in the context of the user’s browser, enabling attackers to steal sensitive information, hijack sessions, or perform unauthorized actions on behalf of the user. XSS attacks are typically classified into three categories: stored, reflected, and DOM-based. Some examples of XSS vulnerabilities are as follows:

1. Stored XSS: Malicious scripts are permanently stored on the target server (e.g., in a database) and served to users when accessing the affected pages.
   Impact: Enables widespread compromise of user accounts or data by executing scripts for multiple users.
   Classification: CWE-79: Improper Neutralization of Input During Web Page Generation
   Example: CVE-2022-21166: Stored XSS in TinyMCE editor.
   
   
2. Reflected XSS: Malicious scripts are embedded in URLs and executed when the victim clicks the link, with no persistent storage on the server.
   Impact: Allows attackers to target specific individuals, stealing sensitive data or redirecting them to malicious sites.
   Classification: CWE-79: Improper Neutralization of Input During Web Page Generation
   Example: CVE-2021-41773: Apache HTTP Server reflected XSS vulnerability.
   
   
3. DOM-based XSS: Malicious scripts manipulate the client-side DOM to execute scripts without involving the server.
   Impact: Can bypass traditional XSS protections on the server, targeting client-side vulnerabilities.
   Classification: CWE-79: Improper Neutralization of Input During Web Page Generation
   Example: CVE-2022-21655: WordPress DOM-based XSS vulnerability.
   
   
4. Mutated XSS: Payloads are encoded or mutated to bypass input filters, only to be decoded and executed on the client.
   Impact: It circumvents typical XSS protections, causing significant difficulty for developers in identifying the root cause.
   Classification: CWE-116: Improper Encoding or Escaping of Output
   Example: CVE-2019-7609: Kibana mutated XSS vulnerability.
   
   
5. Self-XSS: Attackers trick users into running scripts in their own browsers by pasting malicious payloads into their browser console.
   Impact: Users compromise their accounts or data inadvertently.
   Classification: CWE-79: Improper Neutralization of Input During Web Page Generation
   Example: While self-XSS vulnerabilities are not typically assigned CVEs, they remain a common social engineering vector.

Remediation approaches for developers

Developers can significantly reduce the risk of XSS attacks and improve the overall security posture of their applications using these best practices:

1. Use an allowlist: Validate all user inputs against an allowlist of acceptable values to prevent malicious payloads from being accepted.
2. Ensure proper encoding of dynamic content: Ensure all dynamic content is correctly encoded before rendering it on webpages (e.g., using libraries like OWASP Java Encoder).
3. Use frameworks or libraries with built-in XSS protection: Such as React or Angular, which escape output by default.
4. Implement CSP headers: These limit the sources from which scripts can be executed.
5. Sanitize user-generated HTML: If user-generated HTML is allowed, sanitize it using libraries like DOMPurify to strip malicious scripts.
6. Avoid APIs that render content without sanitization: Don’t use eval(), innerHTML, or similar APIs that directly execute or render content without sanitization.

Understanding and mitigating sensitive data exposure

Sensitive data exposure occurs when sensitive information such as personal data, credentials, financial details, or proprietary business information is improperly handled, stored, or transmitted. The attackers can exploit weak security controls, such as unencrypted data transmission, improperly secured databases, or hardcoded credentials, to access or steal sensitive information. This can result in identity theft, financial fraud, regulatory violations, and reputational damage. Some sensitive data exposure misconfigurations can be classified as follows:

1. Unencrypted data transmission: Data is transmitted over insecure channels (e.g., HTTP instead of HTTPS) without encryption.
   Impact: Attackers can intercept and read sensitive data via techniques like packet sniffing, leading to data breaches and unauthorized access.
   Classification: CWE-319: Cleartext Transmission of Sensitive Information
   Example: CVE-2019-3462: APT package manager transmitting sensitive data in plaintext
   
   
2. Exposed database backups: Backup files containing sensitive data are stored in publicly accessible locations.
   Impact: Unrestricted access to backup files can lead to mass data leaks and system compromise.
   Classification: CWE-538: Insecure Handling of Sensitive Information in Backup Files
   Example: CVE-2020-15505: MobileIron device management exposing sensitive backups
   
   
3. Hardcoded credentials: Credentials such as passwords or API keys are embedded in the application source code.
   Impact: Enables attackers to access sensitive systems or data by analyzing code repositories or binaries.
   Classification: CWE-798: Use of Hard-coded Credentials
   Example: CVE-2018-15473: SSH key leakage in Cisco UCS Director
   
   
4. Improper key management: Cryptographic keys that encrypt data are improperly stored, transmitted, or generated.
   Impact: Allows attackers to decrypt sensitive data, nullifying the encryption mechanisms.
   Classification: CWE-522: Insufficiently Protected Credentials
   Example: CVE-2021-22909: Improper key management in Grafana
   
   
5. Publicly accessible cloud storage: Misconfigured cloud storage buckets (e.g., S3) allow unauthorized access to sensitive data.
   Impact: Attackers can download or tamper with sensitive files, leading to data breaches and compliance violations.
   Classification: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
   Example: CVE-2020-17384: Misconfigured S3 buckets exposing sensitive Microsoft data

Remediation approaches for developers

Developers should implement these best practices to mitigate against sensitive data exposure attacks:

1. Always use secure protocols like HTTPS for data transmission: Also, sensitive data stored in databases or files can be encrypted using strong encryption algorithms (e.g., AES-256).
2. Manage cryptographic keys using dedicated tools like AWS KMS or Azure Key Vault: Additionally, rotate keys periodically and restrict their access.
3. Ensure cloud storage buckets are private by default: Explicitly grant access when necessary.
4. Use automated tools to detect misconfigurations: For example, AWS Config or GCP Cloud Security Command Center.
5. Securely store credentials in environment variables or secrets management tools: For example, HashiCorp Vault.
6. Regularly scan code repositories for hardcoded secrets: For example, using tools like GitGuardian.
7. Implement data classification policies: In order to identify and secure sensitive information.
   Ensure compliance with data protection standards: For example, GDPR, PCI DSS, or HIPAA.

Understanding and mitigating authentication and session attacks

Sessions are used to uniquely identify who has authenticated the application and maintain the confidentiality, integrity, and availability of the user and their data to ensure they are not compromised. Authentication and session management vulnerabilities arise when systems fail to properly validate and maintain user identities or sessions. These flaws allow attackers to impersonate users, hijack active sessions, or gain unauthorized access to sensitive accounts. Some examples of authentication and session vulnerabilities are as follows:

1. Credential stuffing: Attackers use large databases of stolen usernames and passwords to try accessing systems via automated tools.
   Impact: Compromised user accounts, leading to identity theft, fraud, or data breaches.
   Classification: CWE-307: Improper Restriction of Excessive Authentication Attempts
   Example: CVE-2020-3452: Cisco VPN portal vulnerability exploitable via credential stuffing.
   
   
2. Session fixation: An attacker provides a valid session ID to the victim, who unknowingly uses it to authenticate, enabling the attacker to hijack the session.
   Impact: Enables full compromise of the victim’s authenticated session.
   Classification: CWE-384: Session Fixation
   Example: CVE-2022-24348: Jenkins session fixation vulnerability.
   
   
3. Weak password policies: Allowing users to set simple, short, or commonly used passwords.
   Impact: Increases the risk of brute force or dictionary attacks to compromise accounts.
   Classification: CWE-521: Weak Password Requirements
   Example: CVE-2018-15715: VMware password policy flaw.
   
   
4. Session hijacking: Attackers steal session cookies or tokens to impersonate a victim's session.
   Impact: Leads to unauthorized access to sensitive data or functions.
   Classification: CWE-287: Improper Authentication
   Example: CVE-2019-18635: Atlassian Jira session hijacking vulnerability.
   
   
5. Missing MFA: Systems rely solely on passwords for authentication without enforcing additional layers like MFA.
   Impact: Increases susceptibility to phishing and credential theft attacks.
   Classification: CWE-287: Improper Authentication
   Example: CVE-2021-27850: Inadequate authentication in Apache OFBiz.

Remediation approaches for developers

Developers can use the following best practices and remediation approaches to ensure the application is safe from authentication and session-related vulnerabilities: 

1. Enforce substantial password requirements: For example, length and complexity. Implement password hashing with secure algorithms (e.g., bcrypt).
2. Introduce rate-limiting or CAPTCHA mechanisms: These can prevent brute force or credential-stuffing attacks.
3. Use secure, HTTP-only cookies for session tokens: Also implement expiration/timeout policies for inactive sessions.
4. Regenerate session IDs upon privilege changes: For example, login or role updates. Also, invalidate old sessions.
5. Mandate MFA for all users: For example, using TOTP, hardware tokens, or SMS-based authentication, especially for privileged accounts.
6. Validate the origin of session tokens: Also, ensure session tokens are bound to specific devices or IP addresses. Enforce logout on suspicious activity.
7. Log and monitor login activity to detect suspicious activity: For example, all login attempts, account lockouts, and password reset requests.
8. Conduct regular pentests: Identify authentication and session-related vulnerabilities through pentesting.

Case studies from Cobalt pentesting clients

Cobalt conducts roughly 5,000 pentests annually, and for a big picture analysis of all those pentests, you can read the State of Pentesting Report 2025. Though it’s a much smaller sample, these two case studies below are real stories from pentests conducted by the members of the Cobalt Core.

Case study 1: Exposed printer service with default credentials

In a recent engagement with a well-known tech company, Cobalt pentesters identified that the client was exposing the printer service web interface publicly. The pentesters, in their first attempt, gained full admin access to the interface using default credentials, and could perform any sensitive action that might lead to business and reputation loss for the organization. 

The pentesters immediately notified the organization, recommending remediations, such as rotating the credentials to a secure password. Within two hours, the issue was resolved, re-tested, and closed through mutual efforts between the organization and the Cobalt team. 

This example underscores how easy it could be for an attacker to find your exposed assets, especially for organizations with a vast attack surface. Cobalt offers external attack surface mapping capabilities that allow you to track your assets in real-time and ensure any unknowns can be identified and avoided before they are actively exploited.

Case study 2: IDOR allows complete account takeover of any user

Cobalt pentesters assessing an application for access control and logical vulnerabilities observed that changing the password of an authenticated user did not require confirming the old password. The testers also noted that the request sent a numerical identifier to define the user for whom the action was performed. 

Upon further exploitation of the endpoint, the team observed that it was vulnerable to IDOR, allowing an attacker to set a password for any user by changing the ID. Since the old password was not required and the endpoint had no rate-limiting in place, the attacker could run a brute force on the numeric ID and change the password for all the users in an automated fashion, leading to a mass account takeover. 

This was reported to the client as a critical issue by the Cobalt pentest management team. The client resolved the issue in a day and requested a re-test, but the testers were able to bypass the implemented check. The team engaged with the client’s developers to explain best practices to help them resolve the issue correctly.

Roles of internal and external security teams

Internal security teams are responsible for establishing and enforcing security policies, conducting regular audits, and ensuring compliance with security standards. While the role of developers and the internal team is to ensure that no misconfigurations are rolling out in the production environment, it is equally essential to have a second check done by engaging external security experts to perform penetration testing, as they provide an unbiased assessment of the organization's security posture.

State of Pentesting Report

The seventh annual State of Pentesting Report offers insights into how businesses use pentesting—and what pentesting reveals about the state of their security programs. 

In this report, find out: 

• The top vulnerabilities and remediation times, by testing type, industry, and organization size.
• How AI/LLM testing shows that many security teams are not equipped to secure genAI implementations.
• Recommendations for building and optimizing a pentesting program as part of an offensive security strategy.

For a deeper look, download the report today.