How to Defend a Web Application with Engineering

We got our CTO, Tom Lindley , to drop us his top tips for building a secure web app. Read on to find out his views on using engineering to shore up your defences.

I’ve been doing lots of interviews recently and one question consistently gets pretty poor or incomplete responses. That question is “How do you build a web application that is secure?”

You get lots of standard responses like; Web Application Firewalls, Static Code Analysis, CSRF Tokens, Input Validation. Yes, all of that stuff is good, but it’s not really what I meant.

Developers are lazy, forgetful, time restricted, under pressure and constantly interrupted, all while trying to maintain a huge mental model of a complex ecosystem in their heads as they build stuff (speaking very much from experience).

The question then is “how do you stop humans making mistakes?”. Well, you can’t, but you can engineer to reduce that scope for error to a minimum. As of 2021 Broken Access Control is now the top item on the OWASP Top 10. Insecure Design has also been added at number 4.

I have been massively influenced by the aviation industry over the last 5 years or so; the safety culture, redundancy and incredible effort put into investigations when things do go wrong. So, I thought I’d write out a concrete example of how we try to use some of these sentiments to reduce developer mistakes by using defence in depth and standardisation.

Standardise & Defence In Depth

The OnSecurity portal application has five standard defences on ingress; these are designed in a standardised format that cannot be easily bypassed (i.e., unless you really try). This design makes it much harder to make something insecure rather than the other way around.

1. Authentication

Firstly, we have authentication middleware that runs on all endpoints defined within a file:

1. In order to add a route without authentication you have to add it to a separate file
2. Git scripts prompt you to recheck any routes added to the non-authenticated file to ensure you meant it
3. Adding a new route to the unauthenticated file will be next to something that is clearly unauthenticated such as forgotten password

2. Security Policies Per API Endpoint

Security policies are applied to all authenticated endpoints. To prevent mistakes we follow these rules:

1. When reviewing PRs we always check new or changed API endpoints. We can immediately spot where security policies are missing from API endpoints.
2. The authenticated endpoint file with the route definitions has git commit scripts that prevent committing code if;

• An access policy has not been defined against the route
• The access policy has been left empty

3. Client Segregation

All models containing client information have an interface on them that runs a standardised query to validate the user has access to the client.

This makes it almost impossible to return information for a client you do not have access to and we have client filtering built into standardised API query ecosystem (mentioned below).

4. Permissions Within Standardised API Queries

1. Standardised API query ecosystem with policies & permissions into it
2. All queries to our database run through a standardised abstraction which enforces policy checks.
3. We use “list” and “view” policies where “list” is considerably lighter weight than “view” to avoid very slow queries.
4. Unit and feature tests run against all list endpoints utilising “view” permission checks rather than “list” to ensure that they do not disagree

5. Controller Level Permissions

This is where we apply additional checks which are mostly business logic rather than grassroots permissions. This level is the most error prone but you can be fairly sure if you get down to this level then everything that should’ve been checked already has been checked.

Summary

This is all obviously very high-level but I'd love to hear from you if you'd like more clarification on any of the above, if you think we've missed anything, or if you think I'm just talking out of my arse.