OWASP TOP 10
OWASP
• OWASP stands for the Open Web Application Security Project,
which is a nonprofit organization focused on improving the
security of software.
• The OWASP community operates globally and is dedicated to
creating freely available security-related resources for
organizations and individuals.
• Their mission is to make software security visible so that
individuals and organizations can make informed decisions
about true software security risks.
OWASP TOP 10
• One of the key contributions of OWASP is the OWASP Top Ten, a
regularly updated list of the ten most critical web application
security risks.
• This list is widely used by organizations to prioritize their
efforts in addressing security issues in web applications.
OWASP
• The OWASP community also develops various tools,
documentation, and best practices to help organizations
improve their software security posture.
• They provide resources for developers, security professionals,
and decision-makers to understand and address security
challenges in the software development lifecycle.
OWASP
• It's important to note that OWASP is not just about web
application security; it covers a broader range of software
security topics and issues.
• The organization encourages collaboration and knowledge-
sharing within the security community to promote better
security practices and awareness.
OWASP TOP 10
• A01:2021-Broken Access Control
• A02:2021-Cryptographic Failures
• A03:2021-Injection
• A04:2021-Insecure Design
• A05:2021-Security Misconfiguration
A01:2021
BROKEN ACCESS CONTROL
• Access control enforces policy such that users cannot act
outside of their intended permissions.
• Failures typically lead to unauthorized information disclosure,
modification, or destruction of all data or performing a
business function outside the user's limits.
A01:2021
BROKEN ACCESS CONTROL
• Common access control vulnerabilities include:
• Violation of the principle of least privilege or deny by default, where
access should only be granted for particular capabilities, roles, or
users, but is available to anyone.
• Bypassing access control checks by modifying the URL (parameter
tampering or force browsing), internal application state, or the HTML
page, or by using an attack tool modifying API requests.
• Permitting viewing or editing someone else's account, by providing its
unique identifier (insecure direct object references)
• Accessing API with missing access controls for POST, PUT and DELETE.
A01:2021
BROKEN ACCESS CONTROL
• Common access control vulnerabilities include:
• Elevation of privilege. Acting as a user without being logged in or
acting as an admin when logged in as a user.
• Metadata manipulation, such as replaying or tampering with a JSON
Web Token (JWT) access control token, or a cookie or hidden field
manipulated to elevate privileges or abusing JWT invalidation.
• CORS misconfiguration allows API access from
unauthorized/untrusted origins.
• Force browsing to authenticated pages as an unauthenticated user or
to privileged pages as a standard user.
A01:2021
BROKEN ACCESS CONTROL
• How to Prevent
• Access control is only effective in trusted server-side code or server-less API,
where the attacker cannot modify the access control check or metadata.
• Except for public resources, deny by default.
• Implement access control mechanisms once and re-use them throughout
the application, including minimizing Cross-Origin Resource Sharing (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.
A01:2021
BROKEN ACCESS CONTROL
• How to Prevent
• Access control is only effective in trusted server-side code or server-less API, where
the attacker cannot modify the access control check or metadata.
• 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.
• Stateful session identifiers should be invalidated on the server after logout.
Stateless JWT tokens should rather be short-lived so that the window of opportunity
for an attacker is minimized. For longer lived JWTs it's highly recommended to follow
the OAuth standards to revoke access.
A02:2021
CRYPTOGRAPHIC FAILURES
• 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 information, and business
secrets require extra protection, mainly if that data falls under
privacy laws, e.g., EU's General Data Protection Regulation
(GDPR), or regulations, e.g., financial data protection such as
PCI Data Security Standard (PCI DSS).
A02:2021
CRYPTOGRAPHIC FAILURES
• Is any data transmitted in clear text? This concerns protocols such as
HTTP, SMTP, FTP also using TLS upgrades like STARTTLS. External
internet traffic is hazardous. Verify all internal traffic, e.g., between
load balancers, web servers, or back-end systems.
• Are any old or weak cryptographic algorithms or protocols 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? Are crypto
keys checked into source code repositories?
• Is encryption not enforced, e.g., are any HTTP headers (browser)
security directives or headers missing?
A02:2021
CRYPTOGRAPHIC FAILURES
• Is the received server certificate and the trust chain properly validated?
• Are initialization vectors ignored, reused, or not generated sufficiently secure for the cryptographic
mode of operation? Is an insecure mode of operation such as ECB in use? Is encryption used when
authenticated encryption is more appropriate?
• Are passwords being used as cryptographic keys in absence of a password base key derivation
function?
• Is randomness used for cryptographic purposes that was not designed to meet cryptographic
requirements? Even if the correct function is chosen, does it need to be seeded by the developer,
and if not, has the developer over-written the strong seeding functionality built into it with a seed
that lacks sufficient entropy/unpredictability?
• Are deprecated hash functions such as MD5 or SHA1 in use, or are non-cryptographic hash functions
used when cryptographic hash functions are needed?
• Are deprecated cryptographic padding methods such as PKCS number 1 v1.5 in use?
• Are cryptographic error messages or side channel information exploitable, for example in the form of
padding oracle attacks?
HOW TO PREVENT
• Classify data processed, stored, or transmitted by an
application. Identify which data is sensitive according to
privacy laws, regulatory requirements, or business needs.
• 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.
HOW TO PREVENT
• Encrypt all data in transit with secure protocols such as TLS with
forward secrecy (FS) ciphers, cipher prioritization by the server, and
secure parameters. Enforce encryption using directives like HTTP Strict
Transport Security (HSTS).
• Disable caching for response that contain sensitive data.
• Apply required security controls as per the data classification.
• Do not use legacy protocols such as FTP and SMTP for transporting
sensitive data.
• Store passwords using strong adaptive and salted hashing functions
with a work factor (delay factor), such as Argon2, scrypt, bcrypt or
PBKDF2.
HOW TO PREVENT
• Always use authenticated encryption instead of just encryption.
• Keys should be generated cryptographically randomly and stored in
memory as byte arrays. If a password is used, then it must be converted
to a key via an appropriate password base key derivation function.
• Ensure that cryptographic randomness is used where appropriate, and
that it has not been seeded in a predictable way or with low entropy. Most
modern APIs do not require the developer to seed the CSPRNG to get
security.
• Avoid deprecated cryptographic functions and padding schemes, such as
MD5, SHA1, PKCS number 1 v1.5 .
• Verify independently the effectiveness of configuration and settings.
A03:2021
INJECTION
• An application is vulnerable to attack when:
• User-supplied data is not validated, filtered, or sanitized by the
application.
• 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 additional, sensitive records.
• Hostile data is directly used or concatenated. The SQL or command
contains the structure and malicious data in dynamic queries,
commands, or stored procedures.
A03:2021
INJECTION
• Some of the more common injections are SQL, NoSQL, OS command,
Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or
Object Graph Navigation Library (OGNL) injection.
• The concept is identical among all interpreters.
• Source code review is the best method of detecting if applications are
vulnerable to injections.
• Automated testing of all parameters, headers, URL, cookies, JSON, SOAP,
and XML data inputs is strongly encouraged.
• Organizations can include static (SAST), dynamic (DAST), and interactive
(IAST) application security testing tools into the CI/CD pipeline to identify
introduced injection flaws before production deployment.
HOW TO PREVENT
• The preferred option is to use a safe API, which avoids using
the interpreter entirely, provides a parameterized interface, or
migrates to Object Relational Mapping Tools (ORMs).
• Use positive server-side input validation. This is not a complete
defense as many applications require special characters, such
as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters
using the specific escape syntax for that interpreter.
• Use LIMIT and other SQL controls within queries to prevent
mass disclosure of records in case of SQL injection.
A04:2021
INSECURE DESIGN
• Insecure design is a broad category representing different weaknesses,
expressed as “missing or ineffective control design.”
• Insecure design is not the source for all other Top 10 risk categories.
• There is a difference between insecure design and insecure implementation.
• We differentiate between design flaws and implementation defects for a
reason, they have different root causes and remediation.
• A secure design can still have implementation defects leading to
vulnerabilities that may be exploited.
• An insecure design cannot be fixed by a perfect implementation as by
definition, needed security controls were never created to defend against
specific attacks.
• One of the factors that contribute to insecure design is the lack of business
risk profiling inherent in the software or system being developed, and thus
the failure to determine what level of security design is required.
HOW TO PREVENT
• Establish and use a secure development lifecycle with AppSec professionals to help
evaluate and design security and privacy-related controls
• Establish and use a library of secure design patterns or paved road ready to use
components
• Use threat modeling for critical authentication, access control, business logic, and
key flows
• Integrate security language and controls into user stories
• Integrate plausibility checks at each tier of your application (from frontend to
backend)
• Write unit and integration tests to validate that all critical flows are resistant to the
threat model. Compile use-cases and misuse-cases for each tier of your application.
• Segregate tier layers on the system and network layers depending on the exposure
and protection needs
• Segregate tenants robustly by design throughout all tiers
• Limit resource consumption by user or service
A05:2021
SECURITY MISCONFIGURATION
• The application might be vulnerable if the application is:
• Missing appropriate security hardening across any part of the
application stack or improperly configured permissions on cloud
services.
• Unnecessary features are enabled or installed (e.g., unnecessary
ports, services, pages, accounts, or privileges).
• Default accounts and their passwords are still enabled and
unchanged.
• Error handling reveals stack traces or other overly informative error
messages to users.
A05:2021
SECURITY MISCONFIGURATION
• The application might be vulnerable if the application is:
• For upgraded systems, the latest security features are disabled or
not configured securely.
• The security settings in the application servers, application
frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc.,
are 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
HOW TO PREVENT
• A repeatable hardening process makes it fast and easy to
deploy another environment that is appropriately locked down.
Development, QA, and production environments should all be
configured identically, with different credentials used in each
environment. This process should be automated to minimize
the effort required to set up a new secure environment.
• A minimal platform without any unnecessary features,
components, documentation, and samples. Remove or do not
install unused features and frameworks.
HOW TO PREVENT
• A task to review and update the configurations appropriate to
all security notes, updates, and patches as part of the patch
management process. Review cloud storage permissions.
• A segmented application architecture provides effective and
secure separation between components or tenants, with
segmentation, containerization, or cloud security groups
(ACLs).
• Sending security directives to clients, e.g., Security Headers.
• An automated process to verify the effectiveness of the
configurations and settings in all environments.
