A user should have access only to the objects and actions that are permitted for that user. Access control can be related to information disclosure, modification or deleting of data, unauthorized file access or performing a function outside of the user’s limits.

Data requires protection both in transit and in rest depending on the sensitiveness of the related data. Passwords, credit card numbers, health records, personal information and so on require extra protection especially when the data falls under privacy laws (e.g. GDPR).

Hostile data from an untrusted source can end up to an interpreter, which executes the injected data. The interpreter can be for example a database (e.g. SQL injection), operating system (e.g. OS command injection) or user’s browser (Cross-site scripting).

The implementations that follow the design precisely are not unconditionally secure as the design may contain flaws. For example, business logic errors, bypassing client-side security and external control of file names and paths expose the system for different types of vulnerabilities.

Security misconfigurations can be faced in many different aspects: for example, there are unnecessary features used, error handling reveals information about system’s internals, and application server, frameworks, libraries, databases etc. are not set to secure values. Although configurations cannot be reviewed directly in black-box testing, misconfigurations show up as security vulnerabilities.

When a component’s name and version number is known, it’s known vulnerabilities can be searched from sites like https://cve.mitre.org/ and https://nvd.nist.gov/. These vulnerabilities are widely known and usually patched to the component’s newest version.

Authentication-related attacks are usually related to confirmation of the user's identity, authentication and session management. Only users with correct credentials should have access to the system. For example, if authentication can be bypassed, external users can get information they are not allowed to access. Session management should always create a new authentication token whenever a user is logged in or logged out and the token should be automatically invalidated after timeout.

Applications, CD/CI pipeline and auto-updates should always have a trusted data source and have sufficient integrity verification. The data that is sent from an attacker is always untrusted and especially serialized data require some form of integrity check or digital signature to prevent insecure deserialization.

When a system is properly monitored and operations are logged, it is easier to detect suspicious actions. There should be logging in the application, logging should raise alerts, the alerts should be monitored and when suspicious activity is observed, there should be actions to handle the situation.

The requests sent by the server should be controlled only by the server. When a web application has a feature to fetch a remote resource, for example an image, SSRF flaws may occur if the URL is not validated by the server. This allows an attacker to force the server to make requests to the addresses defined by the attacker.