OWASP Top 10 Vulnerabilities Cheat Sheet

Injection flaws are very prevalent, partic­ularly in legacy code. Injection vulner­abi­lities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.
An applic­ation is vulnerable to attack when:
• User-s­upplied data is not validated, filtered, or sanitized by the applic­ation.
• Dynamic queries or non-pa­ram­ete­rized calls without contex­taware escaping are used directly in the interp­reter.
• Hostile data is used within object­-re­lat­ional mapping (ORM) search parameters to extract additi­onal, sensitive records.
• Hostile data is directly used or concat­enated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored proced­ures.

There may be authen­tic­ation weaknesses if the applic­ation:
• Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords, such as "­Pas­swo­rd1­" or "­adm­in/­admin“.
• Uses weak or ineffe­ctive credential recovery and forgot password processes, such as "­kno­wle­dge­-based answer­s", which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed passwords.
• Has missing or ineffe­ctive multi-­factor authen­tic­ation.
• Exposes Session IDs in the URL (e.g., URL rewrit­ing).
• Does not rotate Session IDs after successful login.
• Does not properly invalidate Session IDs. User sessions or authen­tic­ation tokens (parti­cularly single sign-on (SSO) tokens) aren’t properly invali­dated during logout or a period of inacti­vity.

The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal inform­ation and business secrets require extra protec­tion, partic­ularly if that data falls under privacy laws, e.g. EU's General Data Protection Regulation
(GDPR), or regula­tions, e.g. financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:
• Is any data transm­itted in clear text? This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. Verify all internal traffic e.g. between load balancers, web servers, or back-end systems.
• Is sensitive data stored in clear text, including backups?
• Are any old or weak crypto­graphic algorithms used either by default or in older code?
• Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing?
• Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing?
• Does the user agent (e.g. app, mail client) not verify if the received server certif­icate is valid?

Applic­ations and in particular XML-based web services or downstream integr­ations might be vulnerable to attack if:
• The applic­ation accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.
• Any of the XML processors in the applic­ation or SOAP based web services has document type defini­tions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet 'XXE Preven­tion’.
• If your applic­ation uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assert­ions, and may be vulner­able.
• If the applic­ation uses SOAP prior to version 1.2, it is likely suscep­tible to XXE attacks if XML entities are being passed to the SOAP framework.
• Being vulnerable to XXE attacks likely means that the applic­ation is vulnerable to denial of service attacks including the Billion Laughs attack.

Access control enforces policy such that users cannot act outside of their intended permis­sions. Failures typically lead to unauth­orized inform­ation disclo­sure, modifi­cation or destru­ction of all data, or performing a business function outside of the limits of the user. Common access control vulner­abi­lities include:
• Bypassing access control checks by modifying the URL, internal applic­ation state, or the HTML page, or simply using a custom API attack tool.
• Allowing the primary key to be changed to another users record, permitting viewing or editing someone else's account.
• Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.
• Metadata manipu­lation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipu­lated to elevate privil­eges, or abusing JWT invali­dation
• CORS miscon­fig­uration allows unauth­orized API access.
• Force browsing to authen­ticated pages as an unauth­ent­icated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.

The applic­ation might be vulnerable if the applic­ation is:
• Missing approp­riate security hardening across any part of the applic­ation stack, or improperly configured permis­sions on cloud services.
• Unnece­ssary features are enabled or installed (e.g. unnece­ssary ports, services, pages, accounts, or privil­eges).
• Default accounts and their passwords still enabled and unchanged.
• Error handling reveals stack traces or other overly inform­ative error messages to users.
• For upgraded systems, latest security features are disabled or not configured securely.
• The security settings in the applic­ation servers, applic­ation frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.
• The server does not send security headers or directives or they are not set to secure values.
• The software is out of date or vulnerable

There are three forms of XSS, usually targeting users' browsers:
Reflected XSS: The applic­ation or API includes unvali­dated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker controlled page, such as malicious watering hole websites, advert­ise­ments, or similar.
Stored XSS: The applic­ation or API stores unsani­tized user input that is viewed at a later time by another user or an admini­str­ator. Stored XSS is often considered a high or critical risk.
DOM XSS: JavaScript framew­orks, single­-page applic­ations, and APIs that dynami­cally include attack­er-­con­tro­llable data to a page are vulnerable to DOM XSS. Ideally, the applic­ation would not send attack­er-­con­tro­llable data to unsafe JavaScript APIs.
Typical XSS attacks include session stealing, account takeover,
MFA bypass, DOM node replac­ement or defacement (such as
trojan login panels), attacks against the user's browser such as
malicious software downloads, key logging, and other client­-side
attacks.

Applic­ations and APIs will be vulnerable if they deseri­alize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks:
• Object and data structure related attacks where the attacker modifies applic­ation logic or achieves arbitrary remote code execution if there are classes available to the applic­ation that can change behavior during or after deseri­ali­zation.
• Typical data tampering attacks, such as access­-co­ntr­ol-­related attacks, where existing data structures are used but the content is changed.
Serial­ization may be used in applic­ations for:
• Remote- and inter-­process commun­ication (RPC/IPC)
• Wire protocols, web services, message brokers
• Cachin­g/P­ers­istence
• Databases, cache servers, file systems
• HTTP cookies, HTML form parame­ters, API authen­tic­ation tokens

You are likely vulner­able:
• If you do not know the versions of all components you use (both client­-side and server­-side). This includes components you directly use as well as nested depend­encies.
• If software is vulner­able, unsupp­orted, or out of date. This includes the OS, web/ap­pli­cation server, database management system (DBMS), applic­ations, APIs and all compon­ents, runtime enviro­nments, and libraries.
• If you do not scan for vulner­abi­lities regularly and subscribe to security bulletins related to the components you use.
• If you do not fix or upgrade the underlying platform, framew­orks, and depend­encies in a risk-b­ased, timely fashion. This commonly happens in enviro­nments when patching is a monthly or quarterly task under change control, which leaves organi­zations open to many days or months of unnece­ssary exposure to fixed vulner­abi­lities.
• If software developers do not test the compat­ibility of updated, upgraded, or patched libraries.
• If you do not secure the compon­ent­s' config­ura­tions

Insuff­icient logging, detection, monitoring and active response occurs any time:
• Auditable events, such as logins, failed logins, and high-value transa­ctions are not logged.
• Warnings and errors generate no, inadeq­uate, or unclear log messages.
• Logs of applic­ations and APIs are not monitored for suspicious activity.
• Logs are only stored locally.
• Approp­riate alerting thresholds and response escalation processes are not in place or effective.
• Penetr­ation testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.
• The applic­ation is unable to detect, escalate, or alert for active attacks in real time or near real time.

You are vulnerable to inform­ation leakage if you make logging and alerting events visible to a user or an attacker