[Blog](/blog) Show links Resources [Blog](/blog) [Breaches](/breaches) [eBooks, reports, & more](/resources) [Events](/events) [News](/news) [Cybersecurity](/category/cybersecurity) Show links Categories [Attack Surface Management](/category/attack-surface-management) [Company News](/category/company-news) [Compliance and Regulations](/category/compliance-and-regulations) [Cybersecurity](/category/cybersecurity) [Data Breaches](/category/data-breaches) [DevOps](/category/devops) [Human Cyber Risk](/category/human-cyber-risk) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) [Third-Party Risk Management](/category/third-party-risk-management) [Vendor Risk Management](/category/vendor-risk-management) [What are the OWASP Top 10?](/blog/owasp-top-ten) Publish date July 4, 2025 {x} minute read # What are the OWASP Top 10? [Get a demo](/contact-sales) [Free trial](/demo) [Download the PDF guide](#) [Free trial](/demo) Written by [Abi Tyas Tunggal](/team/abi-tyas-tunggal) Writer and Senior Product Manager at UpGuard. Abi's work has influenced leaders across cybersecurity, technology, and financial services. Reviewed by [Kaushik Sen](/team/kaushik-sen) Chief Marketing Officer Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education. Table of contents Free resource ### [Download now](#) The OWASP Top 10 is a regularly-updated report outlining the top 10 list of security concerns for web application security.  The report is put together by a team of security experts around the world. OWASP refers to the Top 10 as an 'awareness document' and they recommend all companies incorporate the report's findings into the [cybersecurity](https://www.upguard.com/blog/cyber-security) processes.  ## What is OWASP? The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to improving web application security.  OWASP produces freely-available articles, methodologies, documentation, tools, and technologies, making it possible for anyone to improve their web application security.  The OWASP Top 10 is one of their most well-known projects. ## What are the Top 10 Web Application Security Risks? ### 1. Injection Injection attacks happen when unvalidated or untrusted data is sent to a code interpreter through form input or another data submission field to a web application. Successful injection attacks can result in [data leaks](https://www.upguard.com/blog/data-leak), data corruption, [data breaches](https://www.upguard.com/blog/data-breach), loss of accountability, and denial of access. Almost any source of data can be an injection vector including environment variables, parameters, external and internal web services, and all types of users. For example, an attacker could inject SQL code into a form that expects a plain text username. If the web application developer has not properly sanitized the input, it could result in the SQL code being executed. This is known as an SQL injection attack.  [SQL injection](https://www.upguard.com/blog/sql-injection) is not the only injection flaw. Common [vulnerabilities](https://www.upguard.com/blog/vulnerability) include XPath, NoSQL, [LDAP injections](https://www.upguard.com/blog/ldap), as well as OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.  In general, an application is vulnerable if: * User input is not validated, filtered or sanitized * Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter * Hostile data is used within object-relational mapping (ORM) search parameters to extract [sensitive records](https://www.upguard.com/blog/sensitive-data) * Hostile data is directly used or concatenated, such that the SQL or command contains the structure and hostile data in dynamic queries, commands or stored procedures  To prevent injection attacks, user input should be validated and/or sanitized, and where possible use an API that avoids the use of the interpreter entirely.  For server-side input, whitelist input validation, and use LIMIT and other SQL controls within queries to minimize the amount of [sensitive data](https://www.upguard.com/blog/sensitive-data) that can be exposed. To learn more about preventing injection attacks, OWASP recommends: * [OWASP Proactive Controls: Parameterize Queries](https://owasp.org/www-project-proactive-controls) * [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) * OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection * [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) * [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) * [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) * [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) * [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) * [CWE-77: Command Injection](https://cwe.mitre.org/data/definitions/77.html) * [CWE-89: SQL Injection](https://cwe.mitre.org/data/definitions/89.html) * [CWE-564: Hibernate Injection](https://cwe.mitre.org/data/definitions/564.html) * [CWE-917: Expression Language Injection](https://cwe.mitre.org/data/definitions/917.html) * [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) ### 2. Broken Authentication Authentication systems are some of the most poorly designed and/or implemented systems on many web applications. Additionally, session management is the foundation of any authentication and access control system and is present in all stateful applications.  These vulnerabilities can be detected by an attacker using manual means and exploited using automated tools, [brute force attacks](/blog/brute-force-attack), and dictionary attack tools. [Read our full post on brute force attacks here](/blog/brute-force-attack). The success rate of these attacks can be high. Hundreds of millions of username and password combinations have been exposed in [large data breaches](https://www.upguard.com/blog/biggest-data-breaches). And many people reuse passwords across services or don't bother to change the default administrative login credentials.  Additionally, session management attacks, like cookie hijacking, are well understood and easily exploitable.  OWASP states that a web application has poor authentication if it: * Permits automated attacks, e.g. credential stuffing * Permits [brute force](/blog/brute-force-attack) or other automated attacks * Permits default, weak or well-known passwords ([read our password security checklist](https://www.upguard.com/blog/the-password-security-checklist)) * Uses weak or ineffective credential recovery or forgot password flows, that rely on knowledge-based answers that can be exposed on social media  * Uses plain text, unencrypted or weakly hashed passwords * Has missing or ineffective multi-factor authentication (e.g. no 2FA and [biometrics](https://www.upguard.com/blog/biometrics))  * Exposes Session IDs in the URL * Does not rotate Session IDs after login * Does not properly invalidate session tokens There are a number of ways to prevent [cyber attacks](https://www.upguard.com/blog/cyber-attack) that exploit poor or broken authentication, including: * Multi-factor authentication that prevents automated credential stuffing, brute force, and stolen credential re-use attacks * Never using default credentials * Weak password checks that disallow the [top 10,000 worst passwords](https://github.com/danielmiessler/SecLists/tree/master/Passwords) and ones exposed in known data breaches * Aligning password length, complexity, and rotation policies with [NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) * Ensuring registration, credential recovery, and API pathways are hardened against [enumeration attacks](https://www.upguard.com/blog/what-is-an-enumeration-attack) by returning the same message for all outcomes * Limiting and/or increasing the delay for failed login attempts * Logging all login failures and alerting your security team when credential stuffing, brute force or other attacks are detected * Using server-side, secure, built-in session management that generates a new, random Session ID with high entropy after login * Not exposing Session IDs in the URL * Invalidating user sessions on logout, idle, and absolute timeouts To learn more about preventing broken authentication attacks, OWASP recommends: * [OWASP Proactive Controls: Implement Identity and Authentication Controls](https://owasp.org/www-project-proactive-controls/) * [OWASP Application Security Verification Standard: V2 Authentication](https://owasp.org/www-project-application-security-verification-standard/) * OWASP Application Security Verification Standard: V3 Session Management * [OWASP Testing Guide: Identity, Authentication](https://owasp.org/www-project-web-security-testing-guide/) * [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) * [OWASP Cheat Sheet: Credential Stuffing](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) * [OWASP Cheat Sheet: Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) * [OWASP Cheat Sheet: Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) * [OWASP Automated Threats Handbook](https://owasp.org/www-project-automated-threats-to-web-applications) * [NIST 800-63b: 5.1.1 Memorized Secrets](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) * [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) * [CWE-384: Session Fixation](https://cwe.mitre.org/data/definitions/384.html) ### 3. Sensitive Data Exposure Many web applications and their APIs don't sufficiently protect [sensitive data](https://www.upguard.com/blog/sensitive-data), such as financials, [PHI](https://www.upguard.com/blog/protected-health-information-phi), and [PII](https://www.upguard.com/blog/personally-identifiable-information-pii).  This means rather than attacking the cipher directly, attackers may steal keys, execute [man-in-the-middle attacks](https://www.upguard.com/blog/man-in-the-middle-attack) or steal clear text data from the server, while in transit, from the victim's browser, and increasingly, from a [third-party vendor](https://www.upguard.com/blog/third-party-vendor) who has poor [information security](https://www.upguard.com/blog/information-security).  As organizations store and process more sensitive data and worldwide data protection laws are introduced, this becomes a larger [cybersecurity risk](https://www.upguard.com/blog/cybersecurity-risk) for any web application. With the most common mistake simply not encrypting data at all.  When [encryption is employed](https://www.upguard.com/blog/encryption), weak key generation and management, weak algorithm, protocol, and cipher usage are common, particularly weak password hashing storage techniques.  Failure to protect sensitive data can result in [industrial espionage](https://www.upguard.com/blog/corporate-espionage), reputational damage, financial cost, and increasingly, regulatory action. Driven by new laws and regulations, such as GDPR, [LGPD](https://www.upguard.com/blog/lgpd), [CCPA](https://www.upguard.com/blog/what-is-the-ccpa), [PIPEDA](https://www.upguard.com/blog/pipeda), [HIPAA](https://www.upguard.com/blog/hipaa-privacy-rule), and [CPS 234](https://www.upguard.com/blog/cps-234-compliance) that require the protection of PII, PHI and other sensitive information. Once exposed, credit card numbers, health records, personal information, and trade secrets and result in fraud, identity theft, loss of market position, and cybercrime. To prevent sensitive data exposure, OWASP recommends: * Classifying data processed, stored or transmitted into sensitivity buckets based on laws, regulations, and business needs * Applying controls adequate for the [data classification](/blog/data-classification) * Not storing sensitive data unless necessary * Encrypting sensitive data at rest * Ensuring encryption algorithms are up-to-date and strong * Using proper key management * Encrypting data in transit with secure protocols (e.g. TLS) * Enforcing encryption through [HTTP Strict Transport Security (HSTS)](https://www.upguard.com/blog/hsts) * Not caching sensitive data * Storing passwords using strong, adaptive, and salted hashing functions e.g. [Argon2](https://www.cryptolux.org/index.php/Argon2), [scrypt](https://wikipedia.org/wiki/Scrypt), [bcrypt](https://wikipedia.org/wiki/Bcrypt) or [PBKDF2](https://wikipedia.org/wiki/PBKDF2). * Verifying the effectiveness of configuration and settings [*UpGuard Breach Risk*](https://www.upguard.com/product/breach-risk)* can help you detect leaked credentials and exposed data before it falls into the wrong hands. We were able to detect *[*data exposed in a GitHub repository by an AWS engineer*](https://www.upguard.com/breaches/identity-and-access-misstep-how-an-amazon-engineer-exposed-credentials-and-more)* in 30 minutes. We were able to do this because we actively discover exposed datasets on the open and deep web, scouring S3 buckets, public GitHub repos, and unsecured RSync and FTP servers.* To learn more about preventing sensitive data exposures, OWASP recommends: * [OWASP Proactive Controls: Protect Data](https://owasp.org/www-project-proactive-controls) * [OWASP Application Security Verification Standard (V7, 9, 10)](https://owasp.org/www-project-application-security-verification-standard) * [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) * [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) * [OWASP Cheat Sheet: Password and Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) * [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) * OWASP Testing Guide: Testing for weak cryptography * [CWE-220: Exposure of sens. information through data queries](https://cwe.mitre.org/data/definitions/220.html) * [CWE-310: Cryptographic Issues](https://cwe.mitre.org/data/definitions/310.html) * [CWE-311: Missing Encryption](https://cwe.mitre.org/data/definitions/311.html) * [CWE-312: Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) * [CWE-319: Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) * [CWE-326: Weak Encryption](https://cwe.mitre.org/data/definitions/326.html) * [CWE-327: Broken/Risky Crypto](https://cwe.mitre.org/data/definitions/327.html) * [CWE-359: Exposure of Private Information (Privacy Violation)](https://cwe.mitre.org/data/definitions/359.html) ### 4. XML External Entities (XXE) Attackers can exploit vulnerable Extensible Markup Language (XML) processors that upload XML or include hostile content in an XML document.  This is because many old XML processors allow the specification of an external entity, e.g. a hard drive.   This means that, like injection attacks, XML parsers can be coerced into sending data to an unauthorized external entity, which then passes the sensitive data directly to an attacker.  These flaws can also be used to execute remote requests from the server, scan internal systems, and perform [denial-of-service](https://www.upguard.com/blog/what-is-a-ddos-attack) attacks. To prevent XXE attacks:  * Use simple data formats (like JSON) and avoid serialization of sensitive data * Patch or upgrade all XML processors and libraries in use * Disable XML external entity and DTD processing in XML parsers * Whitelist server-side input * Validate, filter or sanitize input to prevent hostile data within XML documents, headers, and nodes * Verify that XML and XSL upload functionality validates incoming XML using XSD validation or something similar  * Manually review code and use SAST tools to help detect XXEs in source code.  To learn more about preventing XXE attacks, OWASP recommends: * [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard) * [OWASP Testing Guide: Testing for XML Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection) * [OWASP XXE Vulnerability](https://owasp.org/www-community/vulnerabilities/XML_External_Entity_\(XXE\)_Processing) * [OWASP Cheat Sheet: XXE Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) * [OWASP Cheat Sheet: XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) * [CWE-611: Improper Restriction of XXE](https://cwe.mitre.org/data/definitions/611.html) * [Billion Laughs Attack](https://en.wikipedia.org/wiki/Billion_laughs_attack) * [SAML Security XML External Entity Attack](https://secretsofappsecurity.blogspot.tw/2017/01/saml-security-xml-external-entity-attack.html) * [Detecting and exploiting XXE in SAML Interfaces](https://web-in-security.blogspot.tw/2014/11/detecting-and-exploiting-xxe-in-saml.html) ### 5. Broken Access Control [Access control](https://www.upguard.com/blog/access-control) refers to the systems that control access to information or functionality.  Poor access control implementation allows attackers to bypass authorization or perform tasks as though they are privileged users.  For example, a web application may allow a user to change which account they are logged into by changing part of the URL, without any additional verification.  Common access control security vulnerabilities include: * Bypassing access control checks by modifying the URL, internal application state, HTML of the web page, or by using a custom API attack tool  * Allowing the primary key to be changed to another user record, permitting viewing or editing of another user's account * [Privilege escalation attacks](https://www.upguard.com/blog/privilege-escalation) that impersonate a user or allow a user to impersonate an admin * Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT), access control token, cookie, or hidden field * CORS misconfiguration that allows unauthorized API access * Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user To prevent access control access, ensure that access control checks and metadata cannot be modified by: * Denying access by default ([the principle of least privilege](https://www.upguard.com/blog/principle-of-least-privilege)) * Implementing access control mechanisms once and reusing them across the application * Enforcing record ownership rather than accepting users can create, read, update or delete any record * Disabling web server directory listing * Ensuring metadata and backup files are not present within web roots * Logging access control failures and alerting the security team where necessary * Rate limiting APIs and controller access to minimize the impact of automated attacks * Invalidating JWT tokens on logout To learn more about preventing access control exploits, OWASP recommends: * [OWASP Proactive Controls: Access Controls](https://owasp.org/www-project-proactive-controls) * [OWASP Application Security Verification Standard: V4 Access Control](https://owasp.org/www-project-application-security-verification-standard)  * [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-testing)  * [OWASP Cheat Sheet: Access Control](https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html) * [CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)](https://cwe.mitre.org/data/definitions/22.html)  * [CWE-284: Improper Access Control (Authorization)](https://cwe.mitre.org/data/definitions/284.html)  * [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html)  * [CWE-639: Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html)[PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) ### 6. Security Misconfiguration Attackers can exploit unpatched [application vulnerabilities](https://www.upguard.com/blog/vulnerability) or access default accounts, unused pages, unprotected and directories to gain unauthorized access to or gather information on a system.  Misconfiguration can happen at any level of an application stack including network services, platform, web server, application server, database, frameworks, custom code, pre-installed virtual machines, containers, and storage.  To prevent misconfiguration: * Implement an automated [configuration management](https://www.upguard.com/blog/5-configuration-management-boss) policy * Run a repeatable hardening process that makes it easy to deploy another secure environment. See our [Windows Server Hardening Checklist](http://windows%20server%20hardening%20checklist/) * Use a minimal platform without unnecessary features, components, documentation, and samples * Implement [vulnerability management](https://www.upguard.com/blog/vulnerability-management) processes * Segment application architecture to separate components or tenants with segmentation, containerization or cloud security groups  *Misconfiguration doesn't end with your organization. Use *[*UpGuard Vendor Risk*](https://www.upguard.com/product/vendorrisk)* to send *[*security questionnaires*](https://www.upguard.com/blog/vendor-risk-assessment-questionnaire-template)* to third-parties and your *[*security ratings*](https://www.upguard.com/blog/security-ratings-important)* to automatically detect first, third and fourth-party configuration issues and vulnerabilities. * To learn more about preventing misconfiguration, OWASP recommends: * [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-testing) * [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-testing) * [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) * [CWE-2: Environmental Security Flaws](https://cwe.mitre.org/data/definitions/2.html) * [CWE-16: Configuration](https://cwe.mitre.org/data/definitions/16.html) * [CWE-388: Error Handling](https://cwe.mitre.org/data/definitions/388.html) * [CIS Security Configuration Guides/Benchmarks](https://cwe.mitre.org/data/definitions/388.html) * [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) ### 7. Cross-Site Scripting (XSS) [Cross-site scripting (XSS)](/blog/cross-site-scripting-xss) occurs when web applications allow users to add custom code to a URL path or a website that will be seen by other users.  These vulnerabilities can be exploited to run malicious JavaScript on the victim's browser.  For example, an attacker could send a [phishing email](https://www.upguard.com/blog/phishing) to a victim that appears to be from their bank, with a link to the bank's legitimate website.   If the bank doesn't prevent cross-site scripting, the attacker could add malicious JavaScript to the end of the URL, and run it when the link is clicked.   Attackers can also use XSS to stop any automated Cross-Site Request Forgery (CSRF) defenses. To prevent cross-site scripting: * Use modern frameworks that escape XSS by design, such as Ruby on Rails or React * Learn the limitations of a framework's XSS protection and appropriately handle the exceptions  * Escape untrusted HTTP requests  * Validate, filter or sanitize user-generated content * Use a Content Security Policy (CSP) as a [defense-in-depth](https://www.upguard.com/blog/defense-in-depth) control To learn more about preventing XSS, OWASP recommends: * [OWASP Proactive Controls: Encode Data](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) * [OWASP Proactive Controls: Validate Data](https://owasp.org/www-project-proactive-controls) * [OWASP Application Security Verification Standard: V5](https://owasp.org/www-project-proactive-controls) * [OWASP Testing Guide: Testing for Reflected XSS](https://owasp.org/www-project-testing) * [OWASP Testing Guide: Testing for Stored XSS](https://owasp.org/www-project-testing) * [OWASP Testing Guide: Testing for DOM XSS](https://owasp.org/www-project-testing) * [OWASP Cheat Sheet: XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) * [OWASP Cheat Sheet: DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) * [OWASP Cheat Sheet: XSS Filter Evasion](https://owasp.org/www-community//xss-filter-evasion-cheatsheet) * [OWASP Java Encoder Project](https://owasp.org/www-project-java-encoder) * [CWE-79: Improper neutralization of user supplied input](https://cwe.mitre.org/data/definitions/79.html) * [PortSwigger: Client-side template injection](https://portswigger.net/kb/issues/00200308_clientsidetemplateinjection) ### 8. Insecure Deserialization This web security risk targets web applications that frequently serialize and deserialize data. Serialization is the process of translating data structures or object states into a format that can be stored or transmitted, then reconstructed later. Deserialization is the opposite, converting serialized data into objects the application can use.  When data from an untrusted source is deserialized it can result in DDoS attacks and remote code execution.  To prevent insecure deserialization: * Implement integrity checks, such as digital signatures, on any serialized objects to prevent object creation and data tampering * Enforce strict type constraints during deserialization and before object creation  * Isolate and run deserialization code in low privilege environments * Log exceptions and failures, such as when the incoming type is not the expected type or when an exception is thrown * Restrict and monitor incoming and outgoing network traffic from containers or servers that deserialize * Monitor deserialization and alert DevOps if a user deserializes constantly  To learn how to prevent insecure deserialization, OWASP recommends: * [OWASP Cheat Sheet: Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) * [OWASP Proactive Controls: Validate All Inputs](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) * [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard) * [OWASP AppSecEU 2016: Surviving the Java Deserialization Apocalypse](https://speakerdeck.com/pwntester/surviving-the-java-deserialization-apocalypse) * [OWASP AppSecUSA 2017: Friday the 13th JSON Attacks](https://speakerdeck.com/pwntester/friday-the-13th-json-attacks) * [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) * [Java Unmarshaller Security](https://github.com/mbechler/marshalsec) * [OWASP AppSec Cali 2015: Marshalling Pickles](http://frohoff.github.io/appseccali-marshalling-pickles/) ### 9. Using Components with Known Vulnerabilities The use of libraries and frameworks is on the rise, which can introduce vulnerable components that attackers can [exploit](https://www.upguard.com/blog/exploit).  These components speed up software development, helping developers avoid redundant work and providing needed functionality.  Common examples include front-end frameworks like React, back-end frameworks like Ruby on Rails, shared icons or A/B testing solutions.  The most popular components are used by millions of websites, which means if attackers can find security issues in one can leave millions of web applications exposed.  Component developers issue software security patches and updates to fix or mitigate known vulnerabilities (like those listed on [CVE](https://www.upguard.com/blog/cve)), but developers don't always install patches or use the most recent version of components.  To minimize this risk, developers should remove unused components and ensure they are receiving components from a trusted source as malicious sites may post as open source projects to spread [malware](https://www.upguard.com/blog/malware). To prevent known vulnerabilities, OWASP recommends: * [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](https://owasp.org/www-project-application-security-verification-standard) * [OWASP Dependency Check (for Java and .NET libraries)](https://owasp.org/www-project-dependency-check) * [OWASP Testing Guide - Map Application Architecture (OTG-INFO-010)](https://owasp.org/www-project-dependency-check) * [OWASP Virtual Patching Best Practices](https://owasp.org/www-community/Virtual_Patching_Best_Practices) * [The Unfortunate Reality of Insecure Libraries](https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf) * [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cvedetails.com/version-search.php) * [National Vulnerability Database (NVD)](https://nvd.nist.gov/) * [Retire.js for detecting known vulnerable JavaScript libraries](https://github.com/retirejs/retire.js/) * [Node Libraries Security Advisories](https://nodesecurity.io/advisories) * [Ruby Libraries Security Advisory Database and Tools](https://rubysec.com/) ### 10. Insufficient Logging & Monitoring Many web applications do not take the necessary steps to detect data breaches. In fact, [the average discovery time for breach discovery was 206 days in 2019](https://www.upguard.com/blog/cost-of-data-breach). This can give attackers a long time to cause damage before [incident response plans](https://www.upguard.com/blog/incident-response-plan) can kick in. OWASP recommends that applications: * Ensure all login, access control failures, and server-side input validation failures are logged with sufficient context to identify suspicious or malicious accounts and held for sufficient time to allow for delayed [forensic analysis](https://www.upguard.com/blog/digital-forensics) * Have logs generated in a format that can be easily consumed by a centralized log management solution * Have an audit trail for high-value transactions with integrity controls to prevent tampering or deletion, such as append-only database tables * Have effective monitoring and alerting so suspicious activity can be detected and responded to in a timely manner * Establish an incident response plan and disaster recovery plan as outlined in [NIST 700-61 rev 2](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) For further reading, OWASP recommends: * [OWASP Proactive Controls: Implement Logging and Intrusion Detection](https://owasp.org/www-project-proactive-controls) * [OWASP Application Security Verification Standard: V8 Logging and Monitoring](https://owasp.org/www-project-application-security-verification-standard) * [OWASP Testing Guide: Testing for Detailed Error Code](https://owasp.org/www-project-testing) * [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) * [CWE-223: Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) * [CWE-778: Insufficient Logging](https://cwe.mitre.org/data/definitions/223.html) ## How UpGuard Can Reduce Web Risks [UpGuard Vendor Risk](https://www.upguard.com/product/vendorrisk) can minimize the amount of time your organization spends assessing related and third-party information security controls by automating [vendor questionnaires](https://www.upguard.com/blog/planning-your-vendor-security-assessment-questionnaire) and providing [vendor questionnaire templates](https://www.upguard.com/blog/vendor-risk-assessment-questionnaire-template). We can help you continuously monitor your vendors' external security controls and provide an unbiased security rating based on the analysis of 70+ [attack vectors](https://www.upguard.com/blog/attack-vector) including: * [Susceptibility to man-in-the-middle attacks](https://www.upguard.com/blog/man-in-the-middle-attack) * [Insecure SSL/TLS certificates](https://www.upguard.com/blog/ssl-certificate) * [SPF, DKIM and DMARC settings](https://www.upguard.com/blog/email-security) * HTTP Strict Transport Security (HSTS) * [Email spoofing and phishing risk](https://www.upguard.com/blog/email-spoofing) * [Vulnerabilities](https://www.upguard.com/blog/vulnerability) * [Malware susceptibility](https://www.upguard.com/blog/types-of-malware) * Unnecessary open administration, database, app, email and file sharing ports * Exposure to known [data breaches](https://www.upguard.com/blog/data-breach) and [data leaks](https://www.upguard.com/blog/data-leak) * Vulnerable software * HTTP accessibility * Secure cookie configuration * Results of[ vendor risk assessment questionnaires](https://www.upguard.com/blog/vendor-risk-assessment-questionnaire-template) Free resource ### [Download now](#) ## Related posts Learn more about the latest issues in cybersecurity. Attack Surface Management #### [Find Out if You're Exposed on the Dark Web](/blog/find-out-if-youre-exposed-on-the-dark-web) Answer 5 quick questions to predict what a dark web scan will find about your company. Then run the free scan to see your real exposure. [](/team/lance-turner) [Lance Turner](#) October 14, 2026 Data Breaches #### [Your First Dark Web Scan Report, Explained](/blog/your-first-dark-web-scan-report-explained) You scanned your domain. What do the results mean? [](/team/lance-turner) [Lance Turner](#) October 13, 2026 Cybersecurity #### [12 Cybersecurity Horror Stories of 2026 (No Costume Required)](/blog/cybersecurity-horror-stories-2026) A warning ignored once becomes a headline. Read more about these 12 real 2026 cybersecurity incidents, and the sign each one gave before it made the news. [](/team/revashni-moodley) [Revashni Moodley](#) October 14, 2026 Data Breaches #### [Good Security Rating? Your Dark Web Exposure Says Otherwise](/blog/good-security-rating-your-dark-web-exposure-says-otherwise) Scan your domain to see just how exposed you are on the Dark Web. [](/team/lance-turner) [Lance Turner](#) October 13, 2026 Cybersecurity #### [Left Unsupervised: 10 Times Access Outlived Its Authorization](/blog/10-times-access-outlived-authorization) Access granted once shouldn’t mean access forever. Read more on how unmonitored access caused 10 of these real-life breaches and what they taught us. [](/team/revashni-moodley) [Revashni Moodley](#) August 25, 2026 Cybersecurity #### [Surviving a LockBit Ransomware Attack: The ROI of Visibility](/blog/surviving-a-lockbit-ransomware-attack) Read how veteran CISO Nick Gicinto saved his alma mater from a LockBit ransomware attack by discarding the standard playbook. [](/team/nicholas-sollitto) [Nicholas Sollitto](#) June 1, 2026 [All posts](/blog) Experience superior visibility and a simpler approach to cyber risk management [Get a demo](/contact-sales) [Free trial](/demo)