OWASP TOP10 2021

1. Broken Access Control

2. Cryptographic Failures

Data needs to be protected whether in transient or in rest, failure to do so causes cryptographic Failures.

Prevention:

• Make sure to encrypt all sensitive data at rest.
• Discard sensitive data as soon as possible or use PCI DSS compliant tokenization or truncation. Remember: data that is not retained cannot be stolen.
• Classify the data processed, stored, or transmitted by an application.
• 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).
• Disable caching for responses that contain sensitive data.
• Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.

3. Injection

4. Insecure Design(2021)

Lack of effective security controls in the design phase of an application often leads to many weaknesses collectively known as Insecure Design.

Prevention:

Implement and use SDLC.

Use threat modeling for critical authentication, access control business logic and key flows.

5. Security Misconfiguration

• Default configurations (Default Account)
• Improper Error Handling
• Unused pages
• Unprotected files and directories
• Unnecessary services
• Unpatched flaws
• Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws that attackers use to compromise the server. If one of these applications is the admin console and default accounts weren’t changed, the attacker logs in with default passwords and takes over.
• Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. They find and download the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.
• Scenario #3: The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws, such as component versions. They are known to be vulnerable.
• Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows stored sensitive data to be accessed within cloud storage.

6. Vulnerable and Outdated components

Even simple websites such as personal blogs have a lot of dependencies, plugins, extensions and third party code. Failing to update every piece of software on the backend and frontend of a website will introduce heavy security risks sooner rather than later.

Recommendation:

Remove all unnecessary dependencies.

Delete components not actively maintained.

Monitor sources like Common Vulnerabilities and Disclosures (CVE) and National Vulnerability Database (NVD) for vulnerabilities in the components.

7. Identification and Authentication Failures

8. Software and Data Integrity Failures(2021)

Application relies on plugins, libraries, modules from untrusted sources.

Many application nowadays includes auto update features into their application where updates are downloaded without sufficient integrity verification &applied to previously trusted applications.

Insecure CI/CD pipelines can introduce vulnerabilities like unauthorized access, uploading malicious codes into the system leads to system compromise.

Recommendation:

Use software that was digitally signed by a trusted vendor.

For Data Integrity: Ensure that CI/CD has proper segregation, configuration & access control.

9. Security Logging and Monitoring Failures

Servers and websites needs to be monitored on a regular basis. This allows you to take immediate action when something happens.

According to OWASP, these are some examples of attack scenarios due to insufficient logging and monitoring:

• Scenario #1: An open-source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version and all of the forum contents. Although the source could be recovered, the lack of monitoring, logging, or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.
• Scenario #2: An attacker scans for users with a common password. They can take over all accounts with this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.
• Scenario #3: A major U.S. retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before detecting the breach due to fraudulent card transactions by an external bank.

Recommendation

Keeping audit logs give visibility to suspicious changes on your website.

Use EDR and monitor it regularly.

10. Server Side Request Forgery(2021)

Abuse the functionality of the server to read or update internal files.

As cloud services increase in usage and popularity as well as their complexity, the prevalence and risk of SSRF attacks increase too.

How to prevent SSRF in Web Applications

• Whitelist the DNS name or IP address.
• Use deny by default firewall policies.
• Do not send raw responses to users/clients.
• Sanitize all user input.
• Disable unencrypted (HTTP) redirections.

Scenario #1 — Port scan internal servers:

If the network architecture is unsegmented, attackers can map out internal networks and determine if ports are open or closed on internal servers from connection results or elapsed time to connect or reject SSRF payload connections.

Scenario #2 — Sensitive data exposure:

Attackers can access local files such as or internal services to gain sensitive information such as file:///etc/passwd and https://localhost:4444/.

Scenario #3 — Access metadata storage of cloud services:

Most cloud providers have metadata storage such as https://169.254.169.254/. An attacker can read the metadata to gain sensitive information.

Scenario #4 — Compromise internal services:

The attacker can abuse internal services to conduct further attacks such as Remote Code Execution (RCE) or Denial of Service (DoS).