TL;DR: Common web application vulnerabilities map to the security failures they create, from broken access control and injection to SSRF, misconfiguration, and integrity failures, giving practitioners a practical way to prioritise testing, remediation, and control design based on real breach patterns, according to INTIGRITI. The identity lesson is that application flaws often become access-control failures, not just code defects.
At a glance
What this is: This glossary maps common web application vulnerabilities to the access, authentication, configuration, and integrity failures they create.
Why it matters: IAM and security teams can use it to prioritise testing and remediation where application flaws become account takeover, unauthorised access, or broader control compromise.
Context
A web application vulnerability is not just a code defect. In practice, it becomes a governance problem when broken access control, authentication failure, or unsafe data handling lets users or attackers cross trust boundaries the application was supposed to enforce.
This article is especially relevant to IAM because many application flaws manifest as identity failures, not isolated software bugs. When login, session handling, object access, or administrative interfaces are weak, the application stops behaving like a controlled access layer and starts becoming an exposure point.
Key questions
Q: Where does broken access control fail in practice?
A: It fails when the application checks that a user is logged in but does not reliably check whether that user is allowed to reach a specific object, action, or administrative function. That gap lets one account act on another user’s data or cross a privilege boundary without breaking the login flow.
Q: Why do SSRF flaws create such broad exposure in web applications?
A: SSRF is dangerous because the vulnerable application becomes a trusted proxy that can reach internal services, cloud metadata, or hidden endpoints the attacker cannot access directly. Once the server is tricked into making those requests, the attacker can often pivot from web input control to internal data access.
Q: What do teams get wrong about web application security testing?
A: A common mistake is relying only on periodic automated scans or only on manual testing. Automation is essential for speed and coverage, but it will miss subtle logic flaws and unusual abuse paths. Manual testing is needed for creative attack paths, yet it is too costly to do constantly. Strong programmes blend both and retest every day as code changes.
Q: What should teams do when serialized inputs can influence application behaviour?
A: They should assume any unvalidated object or update package can become an execution path, then require integrity checks before the application consumes it. If the application cannot prove the input is trustworthy, it should not use that input to change permissions, state, or code execution.
Technical breakdown
Broken access control and authentication failures
Broken access control appears when the application does not correctly enforce who can see or change a resource. In the identity layer, that often means weak session handling, poor MFA enforcement, brute-force tolerance, or direct object access paths that let one user act as another. Authentication failures and access-control failures often overlap because a weak login boundary is only useful if the post-login authorisation checks are also sound. The result is not just account compromise but the possibility of privilege escalation, impersonation, and administrative misuse inside the application itself.
Practical implication: Test both authentication entry points and post-login authorisation checks, because fixing one without the other leaves the same access path open.
SSRF and security misconfiguration
Server-side request forgery and security misconfiguration become identity problems when internal services, metadata endpoints, admin consoles, or cloud resources are reachable through a trusted application path. SSRF lets attackers push the server into making requests on their behalf, which can expose internal data or credentials if network trust is too broad. Misconfiguration widens the blast radius by leaving admin interfaces exposed, limiting monitoring, or failing to segment sensitive services. In cloud and hybrid environments, these flaws often bridge application security and infrastructure identity controls.
Practical implication: Restrict server egress, lock down administrative surfaces, and verify that internal identity-bearing services are not reachable through untrusted request paths.
Software and data integrity failures
Software and data integrity failures occur when the application trusts code, objects, updates, or serialized inputs that have not been properly validated. Insecure deserialization is a common example because untrusted data can be converted into executable behaviour or privileged application logic. Once integrity checks are weak, an attacker can move from input control to execution control, which may then affect access decisions, data protection, or downstream systems that rely on the application’s output. This is where a web flaw becomes a broader trust failure across the stack.
Practical implication: Validate the integrity of all data that influences application behaviour, especially anything that can alter execution, access decisions, or security-sensitive workflows.
Threat narrative
Attacker objective: The attacker wants to turn a web-facing weakness into unauthorised access, data exposure, or privileged application control.
- Entry begins when a web application accepts malformed requests, weak credentials, or untrusted inputs that bypass intended checks.
- Credential or control abuse follows when the flaw lets the attacker impersonate users, trigger internal requests, or influence privileged application behaviour.
- Impact occurs when the attacker reaches restricted data, administrative functions, or execution paths that should have remained outside the application trust boundary.
Breaches seen in the wild
- ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Web app vulnerability management is really access-governance management in disguise. The article shows that the most damaging web flaws are not abstract code issues but failures in who can access what, under which conditions, and through which trust boundary. For IAM and security teams, that means application testing has to map defects to access paths, not just vulnerability categories.
Broken access control remains the category most likely to collapse identity and application trust together. When login, session, object-level access, or administrative routes are weak, the application stops enforcing separation of duties and becomes a shortcut around policy. That is why application review should treat authorisation as a business control, not only a developer feature.
SSRF exposes the verification trust gap between front-end trust and back-end reality. The application may appear user-facing and safe while still being able to reach internal services, metadata endpoints, or control planes on an attacker’s behalf. Practitioners should treat any service that can make network calls as part of the identity surface, because the server’s own privileges become part of the attack path.
Integrity failures are the hidden bridge between secure coding and privilege abuse. If an application accepts untrusted serialized objects or weakly validated updates, it can turn a data-handling issue into execution, escalation, or data integrity loss. The right governance response is to treat input integrity as a prerequisite for downstream access control and workflow assurance.
Common web app vulnerabilities are increasingly a control-design problem, not a checklist problem. The repeating pattern is that one weak assumption, such as trusting a request, a session, or a serialized object, becomes a chain that crosses multiple safeguards. The practical conclusion is to design for control failure containment, because isolated fixes rarely stop the next exploitation path.
What this signals
Web vulnerability governance now needs to be aligned to identity and access outcomes, not just defect classes. When the same flaw can produce account takeover, data exposure, or internal request abuse, the practical question becomes whether the application is enforcing the right access boundary at every step. Teams should evaluate testing and remediation through that lens rather than relying on a generic vulnerability checklist.
Identity-aware application security is becoming a control-design discipline. The hardest problems in this space are not the presence of flaws but the trust assumptions behind them, especially where sessions, object access, or server-initiated requests can cross policy boundaries. That makes application security, IAM, and cloud control design converge in a way many programmes still do not reflect.
For practitioners
- Tighten access-control testing around resource-level authorisation Validate every object, action, and admin route for direct object access, broken authorisation, and session-bound enforcement rather than relying on login success alone.
- Harden authentication and session boundaries Review brute-force tolerance, MFA enforcement, account lockout rules, and session management so the application cannot be used as a weak identity front door.
- Constrain server-initiated network reach Block unnecessary outbound requests from application servers, especially paths that can reach metadata services, internal APIs, or administrative endpoints.
- Treat admin interfaces as high-risk attack surfaces Restrict exposed administrative consoles to approved networks, remove unused interfaces, and require strong authentication before any privileged function is reachable.
- Verify integrity before execution or deserialization Reject untrusted serialized input, sign or hash sensitive artefacts, and validate any object that can alter code paths, permissions, or workflow state.
Key takeaways
- Common web application vulnerabilities often become identity and access failures rather than standalone coding defects.
- Broken access control, authentication weaknesses, SSRF, misconfiguration, and integrity failures can each widen the blast radius of a web app flaw.
- Practitioners should test and remediate these issues as trust-boundary failures, with special attention to authorisation, session control, and server reachability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centres on attacks that abuse weak authentication, SSRF, and access control paths. |
| Recommendation — Map exposed app behaviours to TA0006 and TA0008 so testing focuses on credential abuse and internal pivot paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Broken access control is the article’s core governance issue across web applications. |
| Recommendation — Apply PR.AA-05 to verify that every resource, action, and admin path is explicitly authorised. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Many examples show excessive access paths or overbroad server reach. |
| Recommendation — Use AC-6 to reduce application and service permissions to the minimum needed for each function. | ||
| OWASP ASVS | V8 — Authorization | The article repeatedly maps vulnerabilities to authorisation failures in the application layer. |
| Recommendation — Validate V8 requirements across object access, function access, and privileged operations before release. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Authentication failures and session abuse are a major part of the glossary’s identity angle. |
| Recommendation — Test API and web login paths for broken authentication so session and token controls cannot be bypassed. | ||
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.
- 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.
- Software Or Data Integrity Failure: A software or data integrity failure happens when a system trusts an artifact, update, or payload without verifying that it is authentic and unchanged. The risk is especially high in CI/CD, package delivery, and runtime updates where unsigned or tampered inputs can be executed as trusted code.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect access governance to the broader security programme.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org