Common Web-Application Security Risks

Most security breaches affecting business web applications do not come from sophisticated nation-state attacks. They come from well-understood weaknesses that were never addressed during development or were introduced later through neglect. For anyone buying, building, or managing a CRM system, customer portal, or internal tool, the practical question is not whether these risks exist in the abstract, but which ones apply to your specific system and what it would take to close the gaps.

Decision summary: Prioritise the risks that could expose data, cross tenant boundaries, abuse privileges or prevent recovery, then require evidence for each mitigation.

The risks that matter most to UK businesses running web applications fall into a small number of categories. Understanding each one in plain terms makes it far easier to have productive conversations with developers, suppliers, and information-security advisers.

A proportionate security baseline

For “Common Web-Application Security Risks”, security controls should be selected from a documented risk assessment and tested in the complete service. No single product, certificate or test removes the need for secure design, access control, monitoring, patching, incident response and recoverable backups.

Authentication and session weaknesses

Authentication is the process of confirming that a user is who they claim to be. When this is done poorly, an attacker can gain access by guessing passwords, reusing credentials stolen from other services, or hijacking an active session. Common failings include allowing weak passwords without enforcement, not offering or requiring multi-factor authentication (MFA), and not invalidating sessions after a reasonable period of inactivity or after a user logs out.

For a customer portal or SaaS product, the impact is direct: someone impersonates a legitimate user and accesses their data, submits orders, or changes account details. For an internal system, a compromised account may give an attacker the same level of access as a trusted employee.

Authorisation failures

Authorisation determines what an authenticated user is allowed to do. Weaknesses here mean a user can reach data or functions they should not. A junior staff member might view management reports, a customer might see another customer's documents, or a standard user might access admin controls.

This category of risk is particularly common in systems that started small and grew organically. When new roles and features are added over time without a clear permissions model, access rules become inconsistent. The system might check permissions on the main dashboard but forget to enforce them on a secondary page or an API endpoint.

Data exposure in transit and at rest

Sensitive business data—customer records, financial figures, personal information covered by UK GDPR—must be protected both while it moves between the user's browser and the server, and while it sits in databases or file storage. The baseline expectation is that all traffic uses HTTPS with a valid certificate, and that data at rest is encrypted where the storage layer supports it. Gaps appear when internal traffic between services is left unencrypted, when backups are stored without encryption, or when sensitive fields are stored in plain text rather than hashed or encrypted.

Outdated components and dependencies

Web applications are built on frameworks, libraries, and platform packages, most of which receive regular security updates. When a system runs an old version of a dependency with a known vulnerability, the risk is not theoretical—public exploit code often exists and can be used by anyone. This is one of the most common entry points for attacks on otherwise well-designed applications.

The challenge for business owners is that this risk is invisible unless someone is actively tracking it. A system can appear to function perfectly while running components with publicly disclosed critical vulnerabilities.

Insecure direct access to records

Many business applications serve records by ID: a URL might include a customer number or an order reference. If the system does not verify that the logged-in user is entitled to view that specific record, anyone who guesses or changes the ID in the URL can access other records. This is not a sophisticated attack—it requires no special tools, just curiosity and a predictable URL structure.

Injection flaws

Injection happens when user-supplied data is treated as an instruction rather than as content. The most widely cited form is SQL injection, where input from a form or URL is inserted into a database query in a way that alters the query's logic. Modern frameworks make this harder than it once was, but it still appears in custom code, legacy systems, and places where developers have bypassed standard query-building methods.

Other forms of injection exist—command injection, LDAP injection—but the underlying pattern is the same: the application trusts input without properly separating it from the instructions it executes.

Misconfigured infrastructure

Not all risks live inside the application code. Cloud storage buckets left open to the public, default credentials on admin panels, unnecessary services running on production servers, and overly permissive firewall rules all create opportunities for unauthorised access. These are configuration problems, not code problems, but their consequences are identical from a business perspective.

How these risks materialise depends heavily on the type of system and how it is used. A customer-facing SaaS product carries different exposure from an internal CRM that never touches the public internet, even though many of the underlying weaknesses are the same.

Customer portals

A portal where clients log in to view documents, track orders, or submit requests is a high-value target because it holds data belonging to many external users. The most consequential risks here are authentication bypass, insecure direct access to another customer's records, and session hijacking. If the portal allows file uploads, additional risks around malicious file handling also apply. The business impact of a breach includes not only data loss but also regulatory reporting obligations under UK GDPR and reputational damage with clients.

Internal business systems and CRMs

Internal systems are sometimes treated as lower risk because they sit behind a VPN or office network. That assumption is fragile. Remote working, compromised employee devices, and phishing attacks all provide paths past the network perimeter. The most relevant risks in this context are authorisation failures—where an employee sees data outside their remit—and insufficient audit logging, which means that if a breach does occur, the business cannot determine what was accessed or changed.

Legacy applications

Older systems present a compounded version of these risks. They may run on unsupported framework versions, use outdated encryption standards, lack modern session management, and have been modified by multiple developers over years without consistent security practices. The risk profile is not simply "old equals insecure," but the probability of unpatched dependencies, inconsistent access controls, and poor logging is materially higher.

Systems with API integrations

When a web application exchanges data with other systems—accounting software, payment processors, third-party CRMs—each integration point is a potential weak spot. Risks include transmitting sensitive data without encryption, accepting data from an integration partner without validation, and not authenticating API calls properly. If an integration uses API keys, the keys themselves become a target: if they are stored in source code, committed to a repository, or not rotated after a staff member leaves, an attacker can use them to access the system directly.

Treating security as a one-time event

The single most common mistake is assuming that a security review at launch means the system stays secure. New vulnerabilities are discovered in frameworks and libraries continuously. Code changes introduce new flaws. Configuration drifts as servers are updated or migrated. Security in a web application is an ongoing process, not a checkbox at project completion.

Relying on obscurity

Some businesses believe that because their application is not widely known or does not handle payment cards, it will not be targeted. Automated scanning tools do not make judgements about how interesting a target is—they find vulnerable systems and exploit them. A system with a known framework vulnerability can be discovered and compromised within hours of being exposed, regardless of the business it serves.

Confusing compliance with security

Meeting a specific compliance requirement—such as completing a self-assessment questionnaire for a client or passing a particular certification—demonstrates that certain controls are in place at a point in time. It does not guarantee that the application is free from the risks described above. Compliance and security overlap, but they are not the same thing.

Key questions to put to a developer or supplier

• How do you track and apply security updates to the frameworks and libraries the application depends on?
• What authentication mechanisms are in place, and is multi-factor authentication available or enforced?
• How are permissions enforced—centrally in one place, or checked individually on each page and endpoint?
• Can a user access a record by changing an ID in the URL, or does the system verify ownership for every request?
• How are API keys, database credentials, and other secrets stored and rotated?
• What logging is in place, and how quickly would you detect unauthorised access?
• What is the process if a critical vulnerability is discovered in a component the application uses?

Limitations of this overview

This article describes common risk categories in general terms. Identifying which risks are present in a specific application requires hands-on examination of the codebase, configuration, and infrastructure. Security is a specialised field, and the regulatory landscape—particularly around data protection in the UK—changes. Any business making decisions about the security of a web application should seek current, specialist advice tailored to their system and circumstances rather than relying solely on general guidance.

Security evidence to require

• Define the protected asset, likely abuse case and evidence that the control still works in production.
• Define the assets, threats, trust boundaries and business impact before selecting controls.
• Give named owners responsibility for patching, access reviews, logging, incident response and recovery testing.
• Prefer phishing-resistant authentication where practical and document recovery paths with the same care as login.

Primary guidance checked for this edition

Sources for “Common Web-Application Security Risks” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• NCSC: Identity and access management
• NCSC: Vulnerability management
• NCSC: Planning cyber-incident response