Web Application Security Guide

Web application security is not a single feature you add at the end of a build. It is a set of decisions that run through every stage of specifying, building, hosting and running a system. For business owners and operations managers, the practical question is not how to become a security engineer, but how to make sound decisions about risk, responsibility and verification when you commission or manage a web application.

Decision summary: Translate the application threat model into layered controls, accountable owners, production evidence and tested recovery.

Security in this context covers several connected layers. Authentication controls who can log in and how their identity is verified. Authorisation determines what each user is allowed to do once inside. Data protection governs how information is stored, transmitted and retained. Infrastructure security covers the servers, databases and cloud services the application runs on. Monitoring and logging provide visibility into what is happening and when something goes wrong.

These layers interact. A well-built authorisation system means little if session tokens are not handled properly. Strong password policies become irrelevant if the database is left accessible to the public internet. The value of a structured approach is that it reduces the chance of a gap between layers going unnoticed until there is a problem.

A proportionate security baseline

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

Where security sits in the project lifecycle

The most effective point to address security is during requirements gathering and specification. Decisions made early — such as whether the system holds personal data, whether it integrates with third-party services, and what user roles exist — shape the security work that follows. Retrofitting security after a system is built is usually more expensive and sometimes structurally difficult.

During development, security takes the form of secure coding practices, input validation, proper session management and careful handling of API keys and credentials. At the hosting stage, it involves network configuration, encryption in transit, access controls on servers and databases, and backup arrangements. After launch, security becomes an operational concern: applying updates, reviewing logs, responding to incidents and periodically reassessing the threat landscape.

Regulatory and contractual drivers

Depending on what your application does and whose data it processes, you may face specific obligations under UK data protection law, industry regulations or contractual commitments to your own customers. Compliance and security are related but not identical. Meeting a regulatory checklist does not guarantee that a system is secure against the threats it actually faces. Conversely, a technically secure system may still fall short of a specific compliance requirement if the documentation and governance around it are absent.

Security and privacy requirements should be reviewed with current specialist legal and information-security advice. The regulatory landscape changes, and the specifics of your data processing activities determine which obligations apply.

Customer portals handling personal data

A portal where customers log in to view their orders, download documents or submit information holds personal data and typically integrates with internal systems. The security considerations here include strong authentication, role-based access so customers see only their own records, encryption of data in transit and at rest, and audit logging of who accessed what and when. The integration points — the APIs connecting the portal to your CRM or back-office systems — need their own access controls and error handling to prevent data leakage through those channels.

Internal business systems and CRMs

Systems used only by staff still require careful security, particularly if they hold employee data, financial information or commercially sensitive records. The threat model is different from a public-facing application: the risk may come less from external attackers and more from inappropriate access by insiders, whether intentional or accidental. Role-based access control, clear permission structures and audit logs become the primary safeguards. Single sign-on integration with your organisation's identity provider can centralise access management and reduce the risk of orphaned accounts when staff leave.

SaaS products serving multiple organisations

Multi-tenant SaaS applications add a further consideration: data isolation between tenants. Each customer organisation needs confidence that its data cannot be accessed by users from another tenant, even if they share the same underlying infrastructure. This affects database design, query patterns, API authorisation and the logging architecture. Security in a multi-tenant system also needs to account for the fact that different tenants may have different compliance requirements, which can influence how and where their data is stored.

Legacy systems being modernised

Older systems often have security characteristics that reflect the era in which they were built: weaker encryption, shared credentials, limited logging and no standardised API layer. When modernising a legacy system, part of the work is understanding what security assumptions were made at the time, which of them are now inadequate, and how to introduce modern controls without breaking the workflows that depend on the system. This is one reason a thorough audit is essential before migration work begins.

Integrations and third-party APIs

Every external integration is a potential attack surface. When your application sends or receives data from a payment provider, a shipping service, an email platform or another business system, you are trusting that connection. Practical security measures for integrations include using authenticated API calls rather than open endpoints, validating all incoming data regardless of its source, handling timeouts and errors gracefully so that a failing third-party service does not expose your system, and keeping API keys and secrets out of your codebase.

Treating security as a one-off activity

A common mistake is to commission a security review before launch and assume the work is done. Security is ongoing. New vulnerabilities are discovered in frameworks and libraries. Your own application changes with each release. The infrastructure it runs on is updated. User behaviour evolves. A practical approach is to build security into your operational rhythm: regular dependency updates, periodic reviews of access permissions, log analysis and scheduled reassessments rather than a single sign-off.

Confusing access with understanding

Giving a business owner admin access to a system is not the same as giving them visibility into its security posture. Access lets you see the data. Understanding security means knowing how authentication works, where logs are stored, who has server-level access, what the backup and recovery process looks like, and what happens when a vulnerability is reported. These are the questions to put to a supplier, and the answers should be specific enough to act on.

Over-reliance on compliance checklists

Checklists such as ISO 27001 or SOC 2 provide useful frameworks, but they describe a management system, not a guarantee against every technical threat. A supplier may hold a certification and still have a specific vulnerability in your application if the scope of the certification does not cover it, or if the controls are not applied consistently. Certifications are a positive signal but should be understood in terms of what they actually cover and what they leave to your own due diligence.

Key questions to put to a supplier

• How is authentication implemented, and is multi-factor authentication available or required?
• How are user roles and permissions structured, and can they be changed without a code deployment?
• Where is data stored, and is it encrypted at rest and in transit?
• How are API keys, database credentials and other secrets managed?
• What is the process for applying security updates to the application and its dependencies?
• What logging is in place, where are logs stored, who has access to them and for how long are they retained?
• What is the incident response process if a security issue is discovered?
• Who has access to the production environment, and how is that access controlled and audited?
• What backup and recovery arrangements exist, and when were they last tested?
• How would we be notified if a vulnerability affecting our system was identified?

Limitations to keep in mind

No web application is completely secure against every possible threat. Security is about managing risk to an acceptable level, not eliminating it entirely. The acceptable level depends on what the system does, what data it holds, what the consequences of a breach would be and how much you are prepared to invest in mitigation. A realistic security position acknowledges these trade-offs rather than promising perfection.

Security measures also carry costs: development time, operational overhead, potential friction for users and ongoing maintenance. Stronger authentication may reduce convenience. Detailed logging increases storage requirements and the need for log management. Tighter API controls may limit integration flexibility. Part of the planning process is balancing these costs against the risks they mitigate, with input from both technical and business perspectives.

What to verify before accepting a system

When you are about to sign off on a delivered web application, the security-related acceptance criteria should be concrete and testable. Rather than accepting a vague statement that the system is secure, verify specific points: that unauthenticated users cannot reach protected pages, that users in one role cannot perform actions restricted to another, that input validation rejects malformed data, that error messages do not expose internal system details, and that logs are being written for the actions that matter to your operations. These checks do not replace a formal security assessment, but they provide a baseline of confidence that the fundamental controls are in place and functioning.

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 “Web Application Security Guide” 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