Top 5 Web Applications Security Risks

1) Broken Access Control

Access control enforces a policy such that users cannot act outside of their intended permissions.
Common access control vulnerabilities include:

* Violation of the principle of least privilege
* Bypassing access control checks by modifying the URL
* Permitting viewing or editing someone else’s account, by providing its unique identifier
* Accessing API with missing access controls
* Accessing API with missing access controls for POST, PUT and DELETE.

How to Prevent:

Access control is only effective in trusted server-side code, where the attacker cannot modify the access control.

* Except for public resources, deny by default.
* Implement access control mechanisms once and re-use them throughout the application.
* Unique application business limit requirements should be enforced by domain models.
* Disable web server directory listing and ensure file metadata.
* Stateful session identifiers should be invalidated on the server after logout.

2) Cryptographic Failures

The first thing is to determine the protection needs of data in transit. For example, passwords, credit cards, etc require extra protection.

* 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?
* Is encryption not enforced, e.g., are any HTTP headers security directives or headers missing?
* Are passwords being used as cryptographic keys in absence of a password base key derivation function?
* Is randomness used for cryptographic purposes that were not designed to meet cryptographic requirements?

How to Prevent:

Do the following, at a minimum, and consult the references:

* Classify data processed, stored, or transmitted by an application.
* Don’t store sensitive data unnecessarily. Discard it as soon as possible.
* Make sure to encrypt all sensitive data at rest.
* Ensure up-to-date and strong standard algorithms, protocols, and keys are in place.
* Disable caching for responses that contain sensitive data.

3) Injections

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.
* The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.

How to Prevent:

Preventing injection requires keeping data separate from commands and queries:

* Prefer to use a safe API, which provides a parameterized interface, or migrates to Object Relational Mapping Tools (ORMs).
* Use positive server-side input validation.
* For any residual dynamic queries, escape special characters.
* Use LIMIT and other SQL controls within queries to prevent mass disclosure of records.

4) Insecure Design

Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.”

* Requirements and Resource Management: Collect and negotiate the business requirements for an application with the business.
* Secure Design: It’s a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested.
* Secure Development Lifecycle: Secure software requires a secure development lifecycle and some form of secure design pattern.

How to Prevent:

* Establish and use a secure development lifecycle with AppSec professionals.
* Establish and use a library of secure design patterns.
* Use threat modeling for critical authentication, access control, business logic, and key flows.
* Integrate security language and controls into user stories.
* Write unit and integration tests to validate that all critical flows are resistant to the threat model.

5) Security Misconfiguration

The application might be vulnerable if the application is:

* Missing appropriate security hardening across any part of the application stack.
* Unnecessary features are enabled or installed.
* Default accounts and their passwords are still enabled and unchanged.
* Error handling reveals stack traces or other overly informative error messages to users.
* For upgraded systems, the latest security features are disabled or not configured securely.

How to Prevent:

Secure installation processes should be implemented, including:

* A repeatable hardening process makes it fast and easy to deploy another environment that is appropriately locked down.
* A minimal platform without any unnecessary features, components, documentation, and samples.
* A task to review and update the configurations appropriate to all security notes, updates, and patches.
* Sending security directives to clients, e.g., Security Headers.
* An automated process to verify the effectiveness of the configurations and settings in all environments.