Security

This section treats web-application security as an operating system of controls, ownership, evidence and recovery rather than a collection of products. Readers should begin with risk and business impact, then follow the relevant guides for identity, data, application, supplier and incident controls.

Decision summary: Build one operating model across identity, authorisation, data, dependencies, monitoring, incidents and recoverable backups.

A proportionate security baseline

For “Security”, 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.

Web application security guide

Security for a business web application is not a single feature you switch on. It is a set of decisions that run through every part of the system: how users log in, what they are allowed to do, how data is stored, how the application talks to other services, and what happens when something goes wrong.

The practical starting point is to understand what you are protecting and why. A customer portal holding contract documents demands different measures from an internal admin panel used by five trusted staff. Both need security, but the scope, rigour and failure consequences differ. Over-securing a low-risk system wastes money; under-securing a high-risk one invites regulatory, reputational and operational damage.

Security decisions should be made during requirements gathering and specification writing, not bolted on before launch. Changing authentication flows, permission models or data-handling rules after development is significantly more expensive than building them in from the start. When you commission a web application, the specification should state clearly what data the system holds, who accesses it, what integrations exist and what the acceptable risk level is. That document then drives every technical choice that follows.

Ownership of security is also a contractual matter. If you use an agency or a SaaS supplier, the contract should set out who is responsible for patching, monitoring, incident response and compliance. Ambiguity here is a common source of disputes after a breach.

Common web-application security risks

Some risks appear repeatedly across business applications, regardless of the technology stack.

Broken access control. A user can view or edit another user's records by changing an identifier in the URL or an API request. This happens when the application checks that the user is logged in but forgets to check whether that specific user is allowed to access that specific record.

Injection flaws. User-supplied data is treated as code rather than text. The most cited example is SQL injection, where input from a form field alters a database query. The same principle applies to command injection, LDAP injection and template injection. The fix is consistent server-side validation and parameterised queries, not client-side checks that a user can bypass.

Authentication weaknesses. Passwords stored without hashing, no rate limiting on login attempts, or password reset flows that can be manipulated. These allow attackers to guess or reset credentials at scale.

Exposed sensitive data. Personal data, API keys or internal identifiers sent over unencrypted connections, stored without encryption, or returned in API responses that the front end does not need. Data exposure is often a design oversight rather than a technical flaw.

Misconfigured permissions. Server directories left open, debug mode enabled in production, or default credentials never changed. These are operational risks rather than code risks, and they are surprisingly common when deployments are handled manually rather than through automated processes.

Outdated dependencies. The application itself may be well-written, but it sits on top of frameworks, libraries and runtime environments that receive security updates. If those are not tracked and applied, known vulnerabilities accumulate.

How to prepare a system for a security review

Whether you are commissioning a penetration test, responding to an auditor, or preparing for a due-diligence check from a prospective client, the preparation is largely the same.

Define the scope precisely. List every URL, subdomain, API endpoint and integrated service that is in scope. State clearly what is out of scope, such as third-party SaaS tools you do not control. Ambiguous scope leads to either missed findings or wasted effort testing systems nobody owns.

Provide documented access. Reviewers need accounts with different permission levels: an administrator, a standard user and any role-based tiers in between. If the system has an API, provide test credentials and documentation. If there are staging or testing environments that mirror production, make those available instead of the live system.

Supply architecture documentation. A reviewer who understands how the application is built, where data flows and what third-party services are involved will produce more relevant findings. This does not need to be exhaustive, but a data-flow diagram and a list of integrations are practical minimums.

Confirm what has already been tested. If you have had previous penetration tests or security reviews, share the reports with findings marked as fixed or accepted. This prevents reviewers from spending time on known issues and focuses attention on what has changed since.

Agree on rules of engagement. State whether the review can include automated scanning, whether it can attempt to disrupt service, and how findings should be communicated during the process. A short written agreement prevents misunderstandings that could themselves cause operational problems.

GDPR and UK data protection for web applications

Any business web application that processes personal data of individuals in the UK is subject to the UK GDPR and the Data Protection Act 2018. This is a legal matter and the specifics of your obligations depend on your data flows, your role as controller or processor, and the nature of the data. What follows is practical guidance on the technical implications, not legal advice.

Data mapping. Before you can protect personal data, you need to know where it is. A data map should show what personal data the application collects, where it is stored, which users and processes can access it, how long it is retained, and whether it is shared with third-party services. This map drives both your security measures and your privacy documentation.

Minimisation and purpose limitation. The application should only collect and retain personal data that is necessary for the stated purpose. In practice, this means questioning every field in a form, every data point stored in a database, and every log entry that includes an email address or IP address. If you cannot explain why you need it, you should not be storing it.

Subject access and deletion. Individuals can request a copy of their personal data or ask for it to be deleted. The application needs to support these requests operationally: can you export a specific user's data, and can you remove it without breaking audit trails or related records that you are legally required to keep? These are design questions, not afterthoughts.

Processor agreements. If your application sends personal data to a third-party service such as a payment provider, an email service or an analytics platform, you need a data-processing agreement in place. From a technical perspective, you also need to understand what that processor does with the data, where it is stored and how you would extract or delete it.

Security as a legal obligation. The UK GDPR requires appropriate technical and organisational measures. This does not prescribe specific tools, but it does mean you need to be able to demonstrate that you have considered the risks and implemented proportionate controls. Documentation of those decisions matters as much as the controls themselves.

How to handle a web application security incident

An incident might be a confirmed breach, a suspicious pattern in logs, a vulnerability report from an external researcher, or a notification from a third-party service that your data has been exposed. The early stages matter more than the technical details.

Detection and triage. Determine what has happened, what systems and data are affected, and whether the incident is ongoing. If you have monitoring and alerting in place, this is faster. If you do not, you may be relying on a user report or a third-party notification, which means you are already behind.

Containment. Stop the bleeding before investigating the cause. This might mean revoking compromised credentials, disabling an integration, taking a specific feature offline, or in severe cases, temporarily suspending access to the application. Containment can be disruptive, but an ongoing breach is worse.

Investigation. Establish how the incident occurred, what data was accessed or exfiltrated, and over what time period. Preserve logs and evidence before they are overwritten. If the investigation requires technical skills your team does not have, this is the point to engage a specialist.

Notification. A personal-data breach that is likely to result in a risk to people’s rights and freedoms must be notified to the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours after the organisation becomes aware of it. You may also need to notify affected individuals. These are legal decisions that should involve appropriate advice. From an operational standpoint, prepare the factual timeline and scope of impact before you need to communicate it.

Recovery and review. Restore services, apply the fix, and then conduct a post-incident review. The review should establish what failed, whether the response was adequate, and what changes would reduce the likelihood or impact of a similar incident. This document is internal, but it is also evidence of responsible behaviour if questions arise later.

Penetration testing: what a business should expect

Penetration testing, often called pen testing, is a structured attempt to find vulnerabilities by simulating the actions of an attacker. It is a point-in-time assessment, not a guarantee of security.

Types of test. A black-box test starts with no internal knowledge, simulating an external attacker. A white-box test provides full access to source code and architecture, simulating a developer or insider with malicious intent. A grey-box test provides limited information, typically user-level access. The choice depends on what you are trying to learn. Black-box tests find what an outsider could discover; white-box tests find deeper flaws but cost more.

What a report should contain. Each finding should include a description of the vulnerability, the steps to reproduce it, an assessment of severity, the potential business impact, and a recommended fix. Severity ratings should be justified, not arbitrary. A good report prioritises findings by risk, not just by technical severity, so you know what to fix first.

What pen testing does not cover. It does not replace secure development practices, code reviews, dependency management or ongoing monitoring. It tests the system as it exists on the day of the test. A fix applied the following day could introduce a new vulnerability. It also does not typically cover social engineering, physical access, or the security of third-party services you integrate with unless those are explicitly scoped.

Retesting. After you fix the findings, ask the tester to retest the specific issues. This confirms the fixes work and have not introduced new problems. Retesting is usually a separate engagement or a defined phase within the original contract.

Web application firewalls: do you need one?

A web application firewall, or WAF, sits between your application and incoming traffic, inspecting requests and blocking those that match known attack patterns. It is a layer of defence, not a substitute for secure code.

What a WAF does well. It can block common automated attacks such as SQL injection attempts, cross-site scripting payloads and requests from known malicious IP addresses. For applications that cannot be patched immediately, a WAF can provide a temporary virtual patch while a fix is developed. It can also reduce noise from automated scanners that constantly probe public-facing applications.

What a WAF does not solve. It cannot fix broken access control, because it does not understand your business logic. It cannot protect against credentials that have been genuinely compromised. It cannot prevent an insider from misusing legitimate access. And if it is misconfigured, it can block legitimate users or, worse, give a false sense of security while the underlying application remains vulnerable.

When it adds value. A WAF is most useful for public-facing applications with a large attack surface, applications that cannot be patched quickly due to legacy constraints, or situations where regulatory requirements explicitly call for one. For an internal admin panel behind authentication and network controls, a WAF is often unnecessary overhead.

Operational cost. A WAF generates alerts and can block legitimate traffic. Someone needs to review blocked requests, tune rules and manage false positives. If you do not have the capacity to do this, the WAF may cause more operational problems than it prevents.

Two-factor authentication for business applications

Two-factor authentication, or 2FA, requires a user to present something they know, such as a password, plus something they have, such as a code from an authenticator app, or something they are, such as a biometric check. The principle is straightforward: even if a password is compromised, the attacker still needs the second factor.

Methods and trade-offs. SMS-based codes are widely understood by users but are vulnerable to SIM-swap attacks and interception. Authenticator apps such as Google Authenticator or Authy are more secure and do not depend on mobile network security. Phishing-resistant authentication can use passkeys or hardware security keys; the operational model must cover supported devices, recovery and any physical-token distribution. Push notifications are convenient but can lead to approval fatigue, where users accept prompts without reading them.

When 2FA is essential. Any application that holds sensitive personal data, financial information, or access to critical business systems should enforce 2FA. For internal tools where all users are on a corporate network with other controls, 2FA may be desirable but less urgent. The decision should be driven by the impact of unauthorised access, not by convenience.

Implementation considerations. For accounts and actions within the approved risk policy, 2FA or stronger authentication should be enforced rather than left to individual preference. The policy may legitimately vary by role, data sensitivity and threat. You also need a recovery process for users who lose their second factor: lost phones, replaced hardware, or expired backup codes. That recovery process itself must be secure, or it becomes the attack vector.

User communication. Introduce 2FA clearly, explaining why it is being added and what users need to do. Provide backup codes and instruct users to store them securely. Poor communication leads to support tickets, frustration and pressure to make 2FA optional.

Data encryption in transit and at rest

Encryption protects data by making it unreadable without the correct key. The distinction between in transit and at rest is important because they address different threats and are implemented differently.

Encryption in transit. This protects data as it moves between the user's browser and your server, and between your server and other services. TLS, the successor to SSL, is the standard mechanism. In practice, this means your application should be served over HTTPS with a valid certificate, and all API calls should use HTTPS. HTTP connections expose data to interception on any network the traffic passes through, including public Wi-Fi and compromised routers.

Encryption at rest. This protects data stored in databases, file storage and backups. If an attacker gains access to the underlying storage, encrypted data is unreadable without the key. Most modern database engines and cloud storage services support encryption at rest, and in many cloud environments it is enabled by default. The question to ask your supplier or development team is not whether encryption at rest exists, but who controls the keys and what happens if those keys are lost or rotated.

What encryption does not do. Encryption does not prevent an authorised user from misusing data they can legitimately read. It does not fix access control problems. And if the application decrypts data before processing it, an attacker who compromises the application layer may access the unencrypted data regardless of storage encryption. Encryption is one layer in a defence-in-depth approach, not a complete solution on its own.

Key management. Encryption is only as strong as the protection of its keys. Keys stored in the same database as the encrypted data, or hardcoded in application source code, undermine the purpose of encryption. Keys should be managed through a dedicated secrets management system, with access restricted and rotation planned.

How to manage secrets and API keys securely

Secrets include database passwords, API keys for third-party services, encryption keys, OAuth tokens and any credential that grants access. How you store and distribute these has a direct impact on your security posture.

Where secrets should not live. Never commit secrets to source-code repositories. Even private repositories can be cloned by anyone with access, and a single leaked clone exposes every secret in the codebase. Do not store secrets in configuration files that are copied between environments, as this leads to production secrets sitting on developer laptops. Do not send secrets by email or instant message.

Environment variables. Injecting secrets via environment variables is a common approach and is adequate for many applications, provided the environment itself is secured. The risk is that environment variables can be logged, included in error reports, or visible to any process running on the same server. For a single-server deployment with limited access, this may be acceptable. For multi-server or containerised environments, it becomes harder to manage.

Secrets management tools. Dedicated tools such as HashiCorp Vault, AWS Secrets Manager or Azure Key Vault provide centralised storage, access logging, automatic rotation and fine-grained permissions. The trade-off is operational complexity: you now have another service to manage, another set of access controls to maintain, and a dependency that your application must be able to reach at startup.

Rotation. Secrets should be rotated periodically and immediately after any suspected exposure. Rotation requires planning: the application needs to be able to read the new secret without downtime, and any service that depends on the old key needs to be updated. If rotation is difficult, it usually means the secret is embedded in too many places, which is itself a problem to fix.

Session management and timeout policies

When a user logs in, the application creates a session: a period during which the user remains authenticated without re-entering credentials. How that session is created, maintained and terminated affects both security and user experience.

Session tokens. Modern applications typically issue a token, often a JWT, that the client sends with each request. The token should be cryptographically signed, contain an expiry time, and carry only the claims necessary for authorisation. Storing excessive data in the token increases its size and the risk of sensitive information being exposed if the token is logged or intercepted.

Where tokens are stored. Storing tokens in local storage makes them accessible to any JavaScript running on the page, including third-party scripts. Storing them in HTTP-only cookies protects against JavaScript access but requires careful configuration to prevent cross-site request forgery. The choice depends on your application's architecture and threat model, and it should be a deliberate decision, not a default.

Timeout policies. Sessions should expire after a period of inactivity. The appropriate duration depends on the application. A customer portal might use a 30-minute idle timeout. An internal admin tool used throughout the day might allow longer sessions but should still have an absolute maximum lifetime. The key is that the timeout should be enforced server-side, not just by hiding the interface after a timer runs out in the browser.

Concurrent sessions. Decide whether a user can be logged in from multiple devices or browsers simultaneously. For most business applications, allowing concurrent sessions is convenient but increases the risk surface: a session on a forgotten device remains active until it expires. Some applications enforce single-session behaviour, where logging in from a new device invalidates the previous session. This is more secure but can frustrate users who switch between devices legitimately.

Logout. The logout function should invalidate the session on the server, not just clear the token from the client. If the token remains valid after logout, it can be reused by anyone who captured it.

Input validation and why it matters

Input validation is the process of checking that data supplied by a user or an external system conforms to expected rules before the application processes it. It is one of the oldest security controls and remains one of the most important.

Server-side always. Validation must happen on the server. Client-side validation improves user experience by providing immediate feedback, but it can be bypassed by disabling JavaScript, modifying the request, or calling the API directly. Any validation that exists only on the client is cosmetic, not protective.

What to validate. Check data type, length, format and range. An email field should accept only strings that match a reasonable email pattern. A quantity field should accept only positive integers within an expected range. A date field should accept only dates in the expected format and within a sensible range. Every field that accepts user input should have explicit validation rules, even if the front-end restricts what can be entered.

Reject unexpected input. The safest approach is to define what is allowed and reject everything else, rather than trying to identify and block what is dangerous. A whitelist of permitted characters, formats and values is more robust than a blacklist of known attack patterns, because new attack patterns emerge constantly.

Consequences of missing validation. Without input validation, the application may process malformed data that causes errors, corrupts records, or triggers unexpected behaviour. In security terms, missing validation is the primary enabler of injection attacks. It can also lead to business logic problems: a negative quantity in an order, a date in the future for a historical record, or a string that overflows a database column.

Validation at boundaries. Validate input when it first enters the system, at API endpoints and form submissions. Internal functions should be able to assume that the data they receive has already been validated. If data passes between internal services, decide whether each service validates independently or trusts the calling service. Trusting upstream services is more efficient but creates a dependency on their validation being correct.

How to respond to a vulnerability disclosure

A vulnerability disclosure is when someone outside your organisation reports a security weakness in your application. This might come from a security researcher, a customer, or an automated scanner. How you respond affects both your security and your reputation.

Do not treat disclosure as an attack. Researchers who report vulnerabilities responsibly, rather than exploiting them or publishing them immediately, are doing you a service. A hostile or legalistic initial response discourages future reports and increases the chance that the next person to find the issue will exploit it or publicise it without warning.

Acknowledge promptly. Respond within a reasonable timeframe to confirm you have received the report, even if you have not yet assessed it. Silence is interpreted as indifference and increases the likelihood of public disclosure.

Triage the report. Determine whether the reported issue is genuine, reproducible, and within the scope of your application. Some reports describe theoretical risks that require unlikely conditions. Others describe real, exploitable vulnerabilities. Assess the severity based on impact and exploitability, not just on the researcher's rating.

Communicate a timeline. Tell the reporter when you expect to have a fix and when you will follow up. If the fix is delayed, update them. Most researchers are willing to wait for a reasonable fix period if you communicate honestly.

Fix and confirm. Apply the fix, test it, and ask the reporter to verify that the vulnerability is resolved. Once confirmed, thank the reporter and, if appropriate, acknowledge their contribution within the bounds of your disclosure policy.

Have a policy before you need one. A published vulnerability disclosure policy on your website sets expectations for researchers and gives your team a process to follow. It should state what is in scope, what types of testing are permitted, how to submit a report, and what response time the reporter can expect.

Security considerations for third-party dependencies

Virtually every web application is built on top of third-party code: frameworks, libraries, packages from public registries, and commercially licensed components. These dependencies introduce capabilities, but they also introduce risk.

Understanding your dependency tree. Your application may directly depend on a small number of packages, but those packages have their own dependencies, which have further dependencies. A vulnerability in a deep, indirect dependency is just as exploitable as one in your own code. You need tooling that can map the full dependency tree, not just the top-level list.

Tracking vulnerabilities. Use automated tools that compare your dependencies against known vulnerability databases such as the National Vulnerability Database or the GitHub Advisory Database. These tools should be part of your build or deployment process so that a newly disclosed vulnerability in a dependency you use triggers an alert.

Applying updates. When a vulnerability is disclosed in a dependency, the fix is usually a version update. The practical challenge is that updates can introduce breaking changes. Test updates in a staging environment before applying them to production. If an update cannot be applied immediately, assess whether a WAF rule, a configuration change, or another mitigation can reduce the risk while you plan the upgrade.

Choosing dependencies. Before adopting a package, consider its maintenance status, the size and responsiveness of its community, its track record for security, and its licence. An unmaintained package with few contributors is a liability that accumulates over time. A package with a permissive licence but no recent commits may be free in financial terms but expensive in risk.

Supply chain risk. High-profile incidents have shown that trusted packages can be compromised, either by the original maintainer or by an attacker who gains access to the package account. This is a difficult risk to eliminate entirely, but you can reduce it by pinning exact versions rather than using loose version ranges, by reviewing changes when you do update, and by minimising the number of dependencies you rely on.

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 “Security” 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