kras99 - stock.adobe.com
Top web app security vulnerabilities and how to mitigate them
These common web application vulnerabilities have been thorns in the side of IT security for years. They are not new -- and neither are their fixes.
The list of top web application security vulnerabilities and risks has remained largely unchanged for the past decade, and the attack vectors are well-known to security practitioners and developers alike. Yet these problems persist, despite their solutions being readily available and well-documented.
Those responsible for application development and design, as well as security managers and directors, should reference the following list of common vulnerabilities to prevent risks from becoming an issue. Read on to discover how to identify and counter web app security challenges.
Access and authentication issues
Problem: Web applications authenticate users and establish sessions to keep track of each user's requests. Failure to protect authentication credentials, access controls and session identifiers leaves applications vulnerable to other flaws. For example, an attacker could use stolen credentials to hijack an active session and assume the identity of a legitimate user; deploy malware or keylogging software; or access, modify or delete data.
Solution: Conduct code reviews, penetration tests and vulnerability scans to identify authentication, access and session management issues.
Adopt a strong identity and access management (IAM) program that includes best practices such as implementing the principle of least privilege (POLP), applying role-based access control (RBAC), requiring MFA and adopting zero-trust security. Establish a strong password policy, limit failed login attempts, audit access controls and review user privileges on a regular basis.
Example: Insecure direct object reference (IDOR)
IDORs occur when an application or API exposes a reference, such as a user ID or file name, that enables an attacker to guess other user IDs or file names. For example, if a user's account ID is displayed in the page URL -- such as https://example.com/user/12345 -- a threat actor could attempt to guess another user's ID and resubmit the request to access that other legitimate user's data. IDOR vulnerabilities result in unauthorized access, privilege escalation and data theft or manipulation.
Do the following to prevent IDORs:
- Use random, unpredictable and unique identifiers and file and object names. Never expose the actual names of objects.
- Implement access control checks on each object a user accesses.
- Use session management to limit how long a user can access their account before they must reauthenticate themselves.
Injection and code execution attacks
Problem: Injection attacks are among the most common -- and most serious -- web application vulnerabilities. They occur when threat actors use carefully crafted data to trick applications into executing unintended commands or accessing unauthorized data.
Types of injection attacks include SQL injection (SQLi), OS injection, email injection, LDAP injection, prompt injection and cross-site scripting (XSS).
Solution: Detect injection vulnerabilities using vulnerability and pen testing, as well as vulnerability scanners and source code analyzers.
To prevent injection flaws, do the following:
- Validate user input. Assume all data, whether user-submitted via a form, URL, cookie or the application's database, is untrusted. Use strict validation functions to ensure data matches expected formats.
- Sanitize user input when HTML is required. Use an HTML sanitizer to clean and parse potentially malicious code from user-submitted data before rendering it in the browser.
- Escape user input. Replace certain characters -- such as <, >, " and & -- with safe text representations using context-aware encoding to prevent them from being interpreted or executed as code.
- Implement a content security policy. Define the specific resources, including scripts and styles, that are permitted to load on a website, as well as their sources and locations.
Example: SQLi
In a SQLi attack, malicious actors take advantage of SQL queries using user-supplied data without first checking to ensure it is valid. Attackers can therefore submit malicious SQL queries and pass commands directly to a SQL database.
In addition to the above prevention advice, limit stored procedures to only those absolutely necessary for conducting transactions. Also, use the HTTPOnly flag on cookies. This prevents the client-side scripts from accessing cookies, reducing the impact of an XSS attack.
Example: XSS
XSS attacks have been around for nearly 40 years. In this attack, malicious actors target an application's users by injecting code -- usually a client-side script, such as JavaScript -- into a web application's output. When a user views the compromised output or webpage, the browser executes, enabling attackers to hijack user sessions; redirect the user to a malicious site; deface the website; and steal the user's cookies, browsing history and other sensitive data.
XSS attacks circumvent the same-origin policy -- a security mechanism that prevents scripts that originate in one website from interacting with scripts in a different site.
Example: Prompt injection
Attackers use prompt injection attacks -- which include direct prompt injection, indirect prompt injection, stored prompt injection and prompt leaking -- to deceive AI tools into disclosing information they would not normally share. For example, an attacker could use a direct prompt injection attack to fool a large language model (LLM) into sharing the system's API keys or secrets.
To prevent prompt injection flaws, ensure prompts cannot bypass or override AI and LLM safeguards, and limit the length of user prompts permitted for AI tools and LLMs.
API and architecture challenges
Problem: APIs are key to how data and services interact and are delivered among businesses, their partners and their customers. Improper implementation and missing security measures in APIs can result in attacks and data loss.
Solution: To mitigate API security risks, do the following:
- Control access to APIs. Use industry standards to authenticate API traffic, follow the POLP and adopt the zero-trust security model.
- Validate data. Avoid malicious inputs by parsing and validating inputs. Never accept raw data.
- Document and test APIs. Create an API registry to document all APIs in use. This also helps prevent shadow APIs. Conduct a risk assessment to assess known vulnerabilities and perform regular security tests to ensure APIs remain secure.
- Follow API key management best practices. Carefully manage and secure API keys and rotate keys regularly.
- Prevent data exposure. Use data loss prevention tools to monitor and detect the oversharing of data.
Example: Broken object-level authorization (BOLA)
BOLA occurs when an app or API fails to properly enforce access controls on objects, enabling attackers to access or modify data they shouldn't have access to. This vulnerability can result in data loss and data manipulation.
To prevent BOLA-related attacks, do the following:
- Implement strong authorization and authentication, including object-level authorization, RBAC and the POLP.
- Use random, unpredictable and unique identifiers.
- Follow secure API design best practices.
- Test APIs for BOLA flaws.
Example: Improperly configured cross-origin resource sharing (CORS)
CORS is a mechanism that enables web applications to securely request resources from other domains, protocols and ports. Improperly configured CORS can result in cross-site request forgery attacks, data exfiltration and unauthorized access.
To prevent misconfigured CORS, do the following:
- Use an allowlist to limit which servers can access restricted resources.
- Implement custom headers to limit the number and kind of headers in CORS requests between servers.
- Regularly test and audit CORS configuration.
Misconfigurations and supply chain risks
Problem: The infrastructure that supports a web application comprises a range of devices and software, including servers, firewalls, databases, OSes and application components. Securing this infrastructure is critical. Equally important is the security of third-party infrastructure, including that of an organization's partners and suppliers.
Several misconfigurations can hinder the security of a web app, including the use of hardcoded or default secrets and credentials, enablement of unnecessary features, use of compromised or vulnerable components, third-party software vulnerabilities, misunderstanding of the shared responsibility model, insider threats and more.
Solution: Run regular vulnerability tests, pen tests, security audits and dependency scans to uncover and remediate any underlying misconfigurations.
To prevent misconfigurations, do the following:
- Adopt secure development best practices.
- Regularly update and patch systems.
- Monitor libraries regularly.
- Remove unused dependencies and components.
- Monitor third-party risks.
- Change default credentials and passwords.
- Implement strong IAM, including the POLP and RBAC.
- Create and update a company software bill of materials (SBOM) that documents all software and libraries in use.
Example: Outdated, vulnerable in-house and third-party infrastructure
Using vulnerable or outdated software libraries, frameworks and software -- including OSes, APIs and runtime environments -- leaves applications open to risks such as data breaches, data loss, privilege escalation, remote code execution, compliance violations and delayed incident response, as well as performance and reliability issues.
This goes for software deployed by the business -- open source and commercial -- as well as the software deployed by the business's third parties.
In addition to the advice offered above, test all open source and third-party code in a sandboxed environment before implementing it. Also, require SBOMs from third-party vendors, integrators, service providers, partners and consultants.
Data security issues
Problem: Common data security issues that plague web applications include, but are not limited to, the following:
- Insecure data storage, such as storing passwords and sensitive data in plaintext and having inadequate database security.
- Data exposure, such as information disclosure, directory traversal and sensitive data in URLs.
- Insufficient data protection, including weak encryption, poor key management and insecure data transmission.
Solution: To prevent these issues, consider the following best practices:
- Adhere to security-by-design principles.
- Follow encryption best practices.
- Hash passwords before storing.
- Follow database security best practices.
- Follow the POLP for database access.
- Classify and handle sensitive data properly.
- Use strong, up-to-date encryption algorithms.
- Follow secure key management practices.
- Use secure data transmission protocols, such as HTTPS and TLS.
Ravi Das is a technical engineering writer for an IT services provider. He is also a cybersecurity consultant at his private practice, ML Tech, Inc., and has the Certified in Cybersecurity (CC) certification from ISC2.
Sharon Shea is executive editor of Informa TechTarget's SearchSecurity site.