Common web app vulnerabilities still expose identity and access controls

At a glance

What this is: This is a glossary of 20 common web application vulnerabilities, with plain-language explanations, real-world examples, and three-step mitigation summaries.

Why it matters: It matters because web application flaws often become access, authentication, and privilege problems that affect human IAM, NHI controls, and the boundary between application security and identity governance.

By the numbers:

• 94% of applications were tested for some form of broken access control, with the average incidence rate of 3.81%, and it has the most occurrences in the contributed dataset with over 318k.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read INTIGRITI’s glossary of common web application vulnerabilities

Context

Web application vulnerabilities become security incidents when broken access control, weak authentication, insecure object access, or misconfiguration lets an attacker reach data or functions they should never see. In practice, that means application defects often become identity failures, because the exploit path usually depends on abused sessions, over-trusted URLs, or inadequate privilege boundaries.

This glossary is useful for practitioners because it groups the most common web risks into recognisable control failures and shows how those failures appear in real breaches. The pattern is familiar across application security and identity programmes: if access, session state, or authorization is weak, attackers rarely need anything more exotic than the app’s own trust model.

The examples are representative rather than unusual, which is exactly why this glossary is valuable for teams building secure-by-design reviews, bug bounty triage, and remediation prioritisation.

Key questions

Q: How should security teams prioritise application vulnerabilities that appear across code and dependencies?

A: Prioritise by exploitability, exposure, and business impact, not by severity alone. A flaw with a known exploit, public reachability, and a critical business function should move ahead of a higher-scoring issue that is isolated or difficult to reach. The goal is to reduce attack surface, not simply clear the longest list.

Q: Why do cryptographic changes matter to IAM and NHI programmes?

A: IAM and NHI programmes rely on certificates, signing keys, and token trust to establish who or what is authenticated. If those cryptographic controls cannot change cleanly, trust flows become brittle, incident recovery slows, and the organisation loses the ability to respond to new standards or vulnerabilities without disruption.

Q: What do teams get wrong about fine-grained access control?

A: Teams often treat fine-grained access control as a coding exercise when it is really an operating model choice. If no one owns policy lifecycle, exception review, and documentation, the access model will expand by accretion rather than design. That is how control becomes fragmented even when the underlying code still seems to work.

Q: How can organisations measure whether AppSec controls are working?

A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.

Technical breakdown

Broken access control and IDOR in web applications

Broken access control occurs when an application fails to enforce who can reach a resource or perform an action. Insecure direct object reference, or IDOR, is a common pattern where predictable identifiers let one user retrieve another user’s data. These flaws often sit above authentication, which means the user is logged in but still able to bypass authorization boundaries. In identity terms, the application is treating possession of an identifier or session as proof of entitlement. That is why access control defects frequently surface in API-driven systems, portals, and admin workflows where object-level checks are inconsistent.

Practical implication: enforce object-level authorization on every request, not just at login or route level.

Injection, SSRF, and why trusted inputs become attack paths

Injection vulnerabilities happen when untrusted input changes what the application executes or requests. SQL injection alters database queries, command injection alters operating-system commands, and SSRF turns the server into a proxy that reaches internal or cloud-resident services. The common failure is trust without validation. In cloud and hybrid environments, SSRF can become especially dangerous because the application may reach metadata services, internal admin endpoints, or privileged backends. These are not separate coding bugs in practice; they are ways of extending the application’s trust boundary beyond what defenders intended.

Practical implication: constrain every external input against allowlists and isolate services that can reach internal or metadata endpoints.

Authentication failure, weak cryptography, and configuration drift

Identification and authentication failures, weak cryptography, insecure storage, and security misconfiguration all reflect the same governance problem: controls exist in theory, but they do not reliably protect secrets, sessions, or data in production. Password handling, MFA enforcement, key storage, and logging are often fragmented across teams and stacks, so protection weakens as applications scale. When this happens, the app stops behaving like a controlled identity surface and starts behaving like a collection of exposed trust decisions. For NHI governance, the same pattern appears when keys, tokens, and service credentials are left static, over-broad, or poorly monitored.

Practical implication: review authentication, secret handling, and logging as one control set rather than separate implementation tasks.

Threat narrative

Attacker objective: The attacker wants to turn a web application flaw into unauthorized access, data theft, or control over privileged functions.

1. Entry begins when an attacker finds an exposed web control such as broken access control, SSRF, or an authentication flaw that lets them reach restricted functions.
2. Escalation follows when the flaw exposes sessions, object references, credentials, or internal services, allowing the attacker to move from user-level access to higher-value data or administrative paths.
3. Impact occurs when the attacker exfiltrates data, alters application logic, or gains enough control to support broader compromise across connected systems.

NHI Mgmt Group analysis

Application security and identity governance now overlap at the point of authorization. Many web vulnerabilities are not just code defects. They are failures in who or what is allowed to access a resource, which is why IAM and AppSec teams need a shared view of access enforcement. If object-level checks, session handling, or API authorization are weak, the application itself becomes an identity bypass surface.

Broken access control is the most important named concept in this glossary because it explains how small flaws become systemic exposure. The problem is not limited to password checks. It also includes IDOR, CSRF, and any design that trusts a user’s position in the flow more than their entitlement to the object. Practitioners should treat object-level authorization as a core governance control, not a code review nicety.

Security misconfiguration turns valid controls into dormant controls. Exposed admin interfaces, missing rate limits, permissive storage, and weak logging all show that a secure architecture can fail at the deployment layer. That is especially relevant for NHI governance because the same deployment drift that exposes a web app often exposes tokens, service accounts, and backend credentials. Practitioners should govern configuration drift as an identity risk as well as a platform risk.

Authentication failures and weak cryptography remain repeatable breach enablers because they scale silently. Teams often fix individual bugs but leave the underlying lifecycle controls untouched. If credential storage, session handling, or encryption practices are inconsistent, the environment accumulates exposure until one weakness is enough. Practitioners should measure control consistency across applications, not just patch individual findings.

This glossary reinforces a broader lesson for the field: application trust boundaries are identity boundaries. Once an application can make decisions on behalf of users, systems, or workloads, its authorization logic becomes part of the enterprise identity model. That means access control, logging, secret handling, and configuration hygiene should be reviewed together. Practitioners should integrate AppSec findings into identity governance reporting.

What this signals

Broken access control should now be treated as a governance metric, not just a test result. If teams can only describe findings by vulnerability class and not by entitlement failure, they are missing the operational pattern that turns application bugs into identity incidents. The useful signal is whether authorization is consistently enforced at the object, action, and session level across the application estate.

Secret handling and access control need to converge in reporting. Web application teams frequently discuss secure coding separately from identity teams, but the practical risk is the same when credentials, session tokens, or backend access paths are exposed. A joined-up programme should measure whether applications can safely store, rotate, and revoke identity material at runtime.

Identity boundaries are increasingly application boundaries. As more business logic moves into APIs and service layers, the question is no longer whether the user authenticated, but whether the application can prove entitlement before every sensitive action. That is why standards such as OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls matter to both AppSec and IAM stakeholders.

For practitioners

• Map each common web flaw to its control owner Assign broken access control, authentication failures, configuration drift, and injection issues to named owners across AppSec, IAM, platform, and engineering so remediation does not stall between teams.
• Test authorization at the object level Add API and UI checks that verify every request is evaluated for entitlement to the specific object, record, or action, not just to the route or session.
• Harden exposed trust boundaries Restrict admin interfaces, metadata access, and internal service reachability with allowlists, segmentation, and service-specific network controls before attackers can pivot through SSRF or misconfiguration.
• Treat secrets and sessions as identity assets Review how applications store passwords, API keys, certificates, and session tokens, then align rotation, monitoring, and revocation with the same lifecycle rules used for other identity credentials.

Key takeaways

• The glossary shows that many web vulnerabilities are really authorization and trust failures that can cross directly into identity risk.
• The most operationally useful patterns are broken access control, authentication weakness, SSRF, and misconfiguration because they so often lead to data exposure or privilege abuse.
• Practitioners should align application testing, secret handling, logging, and access governance so the same control failure is not managed in separate silos.

Key terms

• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Security Misconfiguration: Security misconfiguration is a control failure caused by unsafe defaults, incorrect settings, or overly broad permissions in systems and pipelines. In NHI environments, it often shows up as exposed secrets, persistent roles, or permissive cloud templates. The risk is that routine automation becomes a durable access path.

What's in the full article

INTIGRITI's full glossary covers the operational detail this post intentionally leaves for the source:

• Per-vulnerability mitigation steps in three stages, including how the vendor frames the fix path for each flaw type.
• The full set of 20 mapped web application vulnerability entries with example-driven explanations for testing teams.
• Specific real-world breach examples tied to each vulnerability class, useful when you need a concrete reference for remediation prioritisation.
• The vendor’s own glossary framing and source links for each example if you need to trace the original context.

👉 INTIGRITI’s full glossary includes the mitigation steps and real-world examples behind each vulnerability class.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, identity lifecycle, and workload identity. It is useful for practitioners who need to connect application trust boundaries to identity control design.