Softomate Solutions is a London-based software development studio building secure web applications for UK businesses in professional services, financial technology, healthcare technology, and property. Security is not an optional module in our development process - it is a design constraint applied from the first conversation about architecture. This guide explains what that means in practice, what UK law requires, and how to evaluate whether your current or planned application meets an acceptable standard.
The OWASP (Open Web Application Security Project) Top 10 is the de facto standard list of the most critical web application security risks. Published and updated by a global security community, it reflects the vulnerabilities that are most frequently exploited, most likely to cause serious harm, and most preventable with proper engineering discipline.
For UK businesses commissioning web application development, understanding the OWASP Top 10 gives you a quality benchmark to apply when evaluating your development partner's practices. The current list (2021 edition) covers:
1. Broken Access Control is the number one risk, meaning more applications have access control failures than any other category. Access control is the logic that determines what a user is allowed to see and do. A broken implementation might allow a customer to view another customer's data by changing an ID in a URL, or allow a standard user to access administrative functions. In practice this means ensuring every server-side request validates that the authenticated user is actually authorised to perform the requested action, not just that they are logged in.
2. Cryptographic Failures cover the misuse or absence of encryption. Common failures include storing passwords in plain text (or with weak hashing like MD5), transmitting sensitive data over unencrypted connections, using outdated TLS versions, and failing to encrypt sensitive data at rest. GDPR Article 32 specifically requires appropriate cryptographic measures - this is a legal obligation, not a best practice.
3. Injection includes SQL injection, NoSQL injection, OS command injection, and LDAP injection. SQL injection remains prevalent despite being entirely preventable through parameterised queries and prepared statements. A SQL injection vulnerability can allow an attacker to read, modify, or delete your entire database. Any web application handling user input that touches a database must use parameterised queries without exception.
4. Insecure Design addresses architectural weaknesses that cannot be fixed by correct implementation - the design itself is the problem. Rate limiting on authentication endpoints, brute force protection, and abuse case modelling should be designed in, not added later.
5. Security Misconfiguration covers incorrectly configured servers, cloud services, frameworks, and applications. Examples include default credentials on admin panels, verbose error messages that reveal stack traces to users, unnecessary features and endpoints left enabled, and permissive CORS policies.
6. Vulnerable and Outdated Components means using libraries, frameworks, or infrastructure with known vulnerabilities. Automated dependency scanning tools (Dependabot, Snyk, OWASP Dependency Check) should be part of every CI/CD pipeline.
7. Identification and Authentication Failures covers weak authentication implementations: allowing weak passwords, not implementing multi-factor authentication, insecure session management, and improper credential storage.
8. Software and Data Integrity Failures include insecure deserialization and failure to verify the integrity of software updates, CI/CD pipelines, and critical data.
9. Security Logging and Monitoring Failures means the absence of audit logs that would detect and investigate an attack. Many breaches are undetected for months because organisations have no visibility into what is happening in their applications.
10. Server-Side Request Forgery (SSRF) allows an attacker to induce the server to make HTTP requests to unintended locations, potentially exposing internal services or cloud metadata endpoints.
UK GDPR imposes specific technical security requirements on any organisation processing personal data. Article 32 requires 'appropriate technical and organisational measures' to ensure security proportionate to the risk. For web applications, this translates to:
Pseudonymisation and encryption of personal data. High-risk personal data (health records, financial information, biometric data, criminal records) must be encrypted at rest using current standards (AES-256 is the practical baseline). Data in transit must use TLS 1.2 or 1.3 - TLS 1.0 and 1.1 are deprecated and should be disabled entirely. Pseudonymisation - replacing direct identifiers with non-identifying references where the application logic permits - reduces the impact of any data exposure.
Ongoing confidentiality, integrity, availability, and resilience. This is a process requirement as much as a technical one. It means regular backups with verified restoration procedures, redundant infrastructure for critical applications, and access controls that prevent unauthorised data access by both external attackers and internal staff.
A process for regularly testing, assessing, and evaluating the effectiveness of security measures. Annual penetration testing, quarterly vulnerability scanning, and documented security review processes satisfy this requirement. Ad hoc, untested assumptions about security do not.
72-hour breach reporting to the ICO. If a security incident results in a breach of personal data (unauthorised access, theft, accidental disclosure, or loss of availability), UK GDPR requires reporting to the Information Commissioner's Office within 72 hours of becoming aware. This requires a documented incident response procedure and clear internal escalation paths so that your team knows what constitutes a reportable breach and who is responsible for reporting.
The ICO has fined UK organisations up to ยฃ17.5 million under UK GDPR. More commonly, fines range from ยฃ50,000 to several million pounds for significant breaches involving inadequate security measures. The reputational damage frequently exceeds the financial penalty.
Cyber Essentials is a UK government-backed certification scheme that establishes a baseline of cybersecurity hygiene. It covers five technical controls: firewalls and internet gateways; secure configuration of systems; user access control; malware protection; and patch management (keeping software up to date).
Cyber Essentials Plus adds a third-party technical verification including vulnerability scanning and testing. Some UK government contracts and NHS supply chain contracts require Cyber Essentials certification as a procurement condition. Even where it is not contractually required, the scheme provides a useful baseline that a well-built web application should pass without difficulty.
For web applications specifically, Cyber Essentials requires: input validation; protection against common injection attacks; access control limiting users to only what they need; automatic session timeout; and current, patched software versions throughout the stack. A development team building to OWASP Top 10 standards will naturally satisfy Cyber Essentials requirements for the application layer.
Authentication failures are responsible for a significant proportion of web application breaches. Best practice for UK business applications includes:
Multi-factor authentication (MFA). Any application storing sensitive personal or commercial data should require MFA for user accounts. TOTP (time-based one-time password) apps (Google Authenticator, Authy) provide strong second factors without SMS, which is vulnerable to SIM-swapping attacks. For applications handling financial data, healthcare records, or significant personal information, MFA should be mandatory, not optional.
Session management. Sessions must have a defined expiry, particularly after periods of inactivity. Session tokens must be regenerated after login (to prevent session fixation attacks) and on privilege escalation. Sessions must be fully invalidated on logout - a token that continues to work after the user has logged out is a security vulnerability.
Password policies without the counterproductive rules. NCSC (National Cyber Security Centre) guidance now recommends against mandatory frequent password changes, which push users towards predictable patterns. Instead: enforce a minimum length of 12 characters, check against known breach databases (Have I Been Pwned API), allow password managers by avoiding character restrictions, and implement account lockout or CAPTCHA after repeated failed attempts.
JWT versus sessions. JSON Web Tokens are appropriate for stateless API authentication, particularly in single-page applications communicating with a backend API. Traditional server-side sessions are appropriate for server-rendered applications. Both have security considerations: JWT tokens cannot be invalidated before expiry without additional infrastructure (a token blocklist or short expiry plus refresh token rotation); session tokens require secure, HttpOnly cookies and CSRF protection. Neither is universally superior - the choice depends on your architecture.
A web application penetration test is a structured security assessment performed by qualified security professionals who attempt to identify and (with permission) exploit vulnerabilities in your application. It goes beyond automated scanning to include manual testing of business logic, authentication flows, authorisation controls, and application-specific attack vectors that automated tools cannot replicate.
Commission a penetration test: before launching any application that handles personal data or financial transactions; after significant architectural changes; annually as part of an ongoing security programme; and when regulatory requirements or contractual obligations mandate it. CHECK-accredited testers are the UK government's recommended standard for penetration testing firms.
A web application penetration test from a reputable UK firm typically costs ยฃ3,000 to ยฃ10,000 depending on application complexity, number of user roles, and number of API endpoints. This cost is trivial compared to the cost of a breach, the ICO fine that might follow, and the customer trust lost.
Expect the test to produce a report categorising findings by severity (critical, high, medium, low, informational), with reproduction steps and remediation guidance for each finding. Budget development time for remediation - critical and high findings should be addressed before launch, not after.
Security should be embedded throughout the development process rather than tested at the end. A secure development lifecycle for a bespoke software development project includes:
Beyond the OWASP Top 10, bespoke web applications commissioned by UK businesses exhibit a consistent set of vulnerabilities that arise from the specific conditions of custom development rather than off-the-shelf software:
Insecure direct object references (IDOR). A customer portal that lets users view their own documents at /documents/12345 but does not verify that document 12345 belongs to the authenticated user is a serious vulnerability. This is one of the most common findings in penetration tests of bespoke applications. Every resource retrieval must check that the requesting user is authorised to access that specific resource, server-side, on every request.
Missing rate limiting on sensitive endpoints. Login endpoints without rate limiting are vulnerable to credential stuffing attacks - automated tools testing millions of username/password combinations against a known breach list. Password reset endpoints without rate limiting expose users to email flooding. API endpoints without rate limiting are vulnerable to scraping and abuse. Every endpoint that performs an action of consequence should have per-IP and per-user rate limiting.
Cross-site request forgery (CSRF) on state-changing operations. An application that accepts form submissions without CSRF tokens can be tricked into performing actions on behalf of an authenticated user who visits a malicious website. Modern frameworks (Laravel, Django, Rails) include CSRF protection by default, but custom API endpoints and AJAX handlers require explicit attention.
Verbose error messages in production. Stack traces, database error messages, and internal path references in production error responses give attackers detailed information about your application's internals. Production environments must display generic error messages while logging detailed information internally.
A proper API development discipline addresses these systematically through design patterns rather than individual fixes applied after problems are found.
Yes. The UK GDPR is retained EU law that continues to apply in Great Britain with equivalent obligations to the original EU regulation. The Information Commissioner's Office (ICO) enforces it. If your business also processes data of EU residents, EU GDPR applies to that processing and you may need a European representative. The practical technical obligations - encryption, access control, breach reporting, security measures proportionate to risk - are identical to the EU GDPR requirements your business was already subject to before Brexit.
At minimum, annually and after any significant architectural change. Applications processing financial transactions, health data, or large volumes of personal data should be reviewed more frequently - every six months is reasonable for high-risk applications. Between formal penetration tests, automated vulnerability scanning (OWASP ZAP, Burp Suite Community Edition) and regular dependency updates provide ongoing visibility into emerging risks. Security is a continuous process, not a one-time certification.
Contain the breach immediately - take affected systems offline if necessary to stop the active compromise. Preserve evidence before making changes - logs, snapshots, network traffic captures. Engage a specialist incident response firm if the breach is significant. Report to the ICO within 72 hours if personal data has been affected - this clock starts from when you become aware, not when the breach occurred. Notify affected individuals if the breach is likely to result in high risk to their rights and freedoms. Review and remediate the root cause before restoring services. Document everything throughout for both regulatory and insurance purposes.
Authentication is verifying who you are - the login process. Authorisation is determining what you are allowed to do once authenticated. Many application breaches exploit authorisation failures rather than authentication failures: the user logs in legitimately but then accesses data or functions they should not be able to reach. Common examples include accessing another user's records by changing an ID in a URL, escalating privileges by modifying a hidden form field, or accessing admin functionality by directly visiting a URL that was never linked from the UI. Both layers require independent, server-side enforcement on every request.
Yes, and significantly more than most small business owners assume. Automated scanning tools probe every public-facing web application continuously, regardless of business size. A small business with a vulnerable web application is not beneath notice - it is simply a target that most attackers expect to be less well defended. The ICO has issued fines to small businesses for GDPR breaches resulting from inadequate security measures. Cyber insurance premiums are rising sharply, and several insurers now require evidence of basic security controls as a condition of coverage. The cost of preventive security engineering is consistently lower than the cost of breach response.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
