What is OWASP?
OWASP stands for the Open Web Application Security Project, an online community that produces articles, methodologies, documentation, tools, and technologies in the field of web application security.OWASP Top 10 is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures.

1. INJECTION
Allowing hostile data to be sent as part of a command or query
Dynamic web applications occasionally need to run commands on the underlying database or operating system to update data, execute a script or start other apps. If unvalidated inputs are added to a command string, attackers can launch commands at will to take control of a server, device or data.

How does it work?
If a website, app, or device incorporates user input within a command, an attacker can insert a “payload” command directly into said input. If that input is not verified, an attacker then “injects” and runs their own commands. Once attackers can make commands, they can control your website, apps and data.

Ways to mitigate Injection
•Use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface or migrate
to use Object Relational Mapping Tools (ORMs).
•Use positive or “whitelist” server-side input validation
•Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
•Ensure that the web application runs with only the privileges it absolutely needs to perform its function.

2. BROKEN AUTHENTICATION
Incorrectly implemented authentication and session management functions.
Incorrect implementation of authentication and session management functions in applications allows attackers to compromise data such as passwords, keys and session tokens or to exploit other implementation flaws to masquerade identities temporarily or permanently.
Attackers have access to millions of valid username and password combinations which can be used in credential stuffing, default administrative account lists, automated brute force and dictionary attack tools. Unexpired session tokens due to poor session management is the main vulnerability behind session management attacks.

How does it work?
In the simplest attacks, passwords can be guessed or stolen if left unprotected. As complexities are added, attackers can find other areas where user credentials or sessions have inadequate protections and then hijack a user’s access, and eventually their data.

Ways to mitigate Broken Authentication
•Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute
force, and stolen credential re-use attacks.
•Do not ship or deploy with any default credentials, particularly for admin users.
•Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst
passwords.
•Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for
Memorized Secrets or other modern, evidence-based password policies.
•Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by
using the same messages for all outcomes.
•Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential
stuffing, brute force, or other attacks are detected.
•Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after
login. Session IDs should not be in the URL. Ids should also be securely stored and invalidated after logout,
idle, and absolute timeouts.

3. SENSITIVE DATA EXPOSURE
Many web technologies weren’t designed to handle financial or personal data transfers
Sensitive data, such as credit card numbers, health data, or passwords, should have extra protection given the potential of damage if it falls into the wrong hands. There are even regulations and standards designed to protect sensitive data. But, if sensitive data is stored, transmitted, or protected by inadequate methods, it can be exposed to attackers.

How does it work?
If data is stored or transferred as plain text, if older/weaker encryption is used, or if data is decrypted carelessly, attackers can gain access and exploit the data. Once an attacker has passwords and credit card numbers, they can do real damage.

Ways to mitigate Sensitive data exposure
•Classify data processed, stored, or transmitted by an application.
•Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
•Apply controls as per the classification.
•Don’t store sensitive data unnecessarily.
•Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not
retained cannot be stolen.
•Make sure to encrypt all sensitive data at rest.
•Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key
management.
•Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers,
cipher prioritization by the server, and secure parameters.
•Enforce encryption using directives like HTTP Strict Transport Security (HSTS).

4. XML EXTERNAL ENTITIES
XML “entities” can be used to request local data or files
XML External Entity injection is also known as XXE is an attack based on Server-Side Request Forgery (SSRF). XXE attack manipulates a rarely used feature of XML parsers to do denial of service attacks, gain access to local and remote content and services and remote code execution. There are two types of XXE attacks as in-band and out-of-band.

How does it work?
An attacker sends malicious data lookup values asking the site, device, or app to request and display data from a local file. If a developer uses a common or default filename in a common location, an attacker’s job is easy.

Ways to mitigate XML External Entities
•Whenever possible, use less complex data formats such as JSON, and avoid serialization of sensitive data.
•Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating
system.
•Use dependency checkers (update SOAP to SOAP 1.2 or higher).
•Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet
‘XXE Prevention’.
•Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
•Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
•SAST tools can help detect XXE in source code – although manual code review is the best alternative in large, complex applications with many integrations.

5. BROKEN ACCESS CONTROL
Improper enforcement of what authenticated users are allowed to do
Access control is there to restrict access on data and functions for unwanted parties. If access control is not implemented properly It will lead to broken access control which allows attackers to exploit vulnerability to access unauthorized critical data and functions.

How does it work?
Sometimes, gaining unauthorized access is as simple as manually entering an unlinked URL in a browser, such as, http://example.com/admin..

Ways to mitigate Broken access control
•With the exception of public resources, deny by default.
•Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
•Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
•Unique application business limit requirements should be enforced by domain models.
•Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
•Log access control failures, alert admins when appropriate (e.g. repeated failures).
•Rate limit API and controller access to minimize the harm from automated attack tooling.
•JWT tokens should be invalidated on the server after logout.

6. Security misconfiguration
Manual, ad hoc, insecure, or lack of security configurations that enable unauthorized access
Security misconfiguration is the most common vulnerability on the list, and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

How does it work?
People get busy, things get missed, prioritization decisions are made. and vulnerabilities are left unchecked.

Ways to mitigate Security misconfiguration
•A minimal platform without any unnecessary features, components, documentation, and samples.
•Remove or do not install unused features and frameworks.
•An automated process to verify the effectiveness of the configurations and settings in all environments.
•An automated process to verify the effectiveness of the configurations and settings in all environments.

7. Cross site scripting
A web application includes untrusted data in a new web page without proper validation
Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a URL path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser.

How does it work?
When a web page or app utilizes user-entered content as part of a resulting page without checking for bad stuff, a malicious user could enter content that includes HTML entities.

Ways to mitigate Cross site scripting
•taking the data an application has received and ensuring it’s secure before rendering it for the end user.
•By escaping user input, key characters in the data received by a web page will be prevented from being interpreted in any malicious way
•ensuring an application is rendering the correct data and preventing malicious data from doing harm to the site, database, and users.
•While whitelisting and input validation are more commonly associated with SQL injection, they can also be used as an additional method of prevention for XSS
•Sanitizing data is a strong defense, but should not be used alone to battle XSS attacks.

8. Insecure Deserialization
Receipt of hostile serialized objects resulting in remote code execution
Before data is stored or transmitted, the bits are often serialized so that they can be later restored to the data’s original structure. Reassembling a series of bits back into a file or object is called deserialization.

How does it work?
Deserialized data can be modified to include malicious code, which is likely to cause issues if the application does not verify the data’s source or contents before deserialization. Attackers can build illegitimate objects that execute commands within an infected application.

Ways to mitigate Insecure Deserialization
•Ways to avoid insecure deserialization include:
•Monitoring the deserialization process.
•Encrypting serialization processes.
•Not accepting serialized objects from unknown or untrusted sources.
•Running the deserialization code with limited access permissions.
•Using a firewall which can help detect insecure deserialization.

9. Using Components with Known Vulnerabilities
Finding and exploiting already known vulnerabilities before they are fixed
Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks.

Ways to mitigate Using Components with Known Vulnerabilities
•Remove unused dependencies, unnecessary features, components, files, and documentation.
•Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries).
•Only obtain components from official sources over secure links.
•Monitor for libraries and components that are unmaintained or do not create security patches for older versions.

10. Insufficient Logging & Monitoring
Receipt of hostile serialized objects resulting in remote code execution
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

Ways to mitigate Insufficient Logging & Monitoring
•Ensure that logs are generated in a format that can be easily consumed by a centralized log management solution.
•Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
•Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts