If your web application holds customer or staff data, the basics that matter most are: strong login controls, access limited to what each person needs, encryption in transit and at rest, prompt patching, tested backups and a plan for when something goes wrong. None of this requires a security department. It requires a developer who treats it as part of the build.
Use this checklist when commissioning an app, or to review one you already run.
1. Logins and access
- Passwords are stored hashed, never in plain text.
- Multi-factor authentication is available, and required for administrators.
- Each user sees only what their role needs. Test this by logging in as one customer and trying to open another’s records.
- Sessions expire, and logging out really ends them.
- Admin areas are not on a guessable address without protection.
2. Protecting the data
- Traffic uses HTTPS everywhere, with no mixed content.
- Sensitive data is encrypted at rest.
- You collect only the personal data you have a reason to hold. Data you never collect cannot leak.
- You know where the data is stored. Many UK businesses prefer UK-resident hosting.
- There is a defined retention period and a way to delete a person’s data when required under UK GDPR.
3. The code itself
Most attacks on web apps use well-known weaknesses. Ask your developer how the app deals with:
- injection attacks, where malicious input is run as a command
- cross-site scripting, where hostile content runs in another user’s browser
- broken access control, where a user changes an ID in the address bar to see someone else’s data
- file uploads, which must be validated and stored safely
The OWASP Top 10 is the standard list. A competent developer will know it and be able to say how each item is handled.
4. Keeping it patched
Apps are built from dozens of third-party packages, and vulnerabilities in them are found constantly. Someone has to update them. This is the item most often neglected after launch, and it is the main reason maintenance plans exist. Ours include security patching and dependency updates from £199 a month; see website and web app support.
5. Backups and recovery
- Backups run daily and are stored separately from the live system.
- Someone has actually tested a restore. An untested backup is a hope, not a backup.
- You know how long recovery would take and what would be lost.
6. Logging and monitoring
- Important actions, such as logins, data exports and permission changes, are logged: who, what, when.
- Someone is alerted if the site goes down or errors spike.
- Logs do not contain passwords or full card numbers.
7. Your organisation, not just the code
- Staff use unique accounts, not shared logins.
- People who leave lose access the same day.
- Developers do not keep production passwords in email or chat.
- Secrets such as API keys are kept out of the source code.
8. Certification and assurance
Cyber Essentials is a UK government-backed scheme that checks the basic controls: firewalls, secure configuration, access control, malware protection and patching. Many public-sector and corporate buyers ask for it. Nerdster Design is Cyber Essentials certified, and it is a reasonable thing to ask any supplier. For applications handling sensitive data, an independent penetration test goes further.
Questions to put to your developer
- How is access to other users’ data prevented, and how was it tested?
- Who patches dependencies after launch, and how often?
- Where is the data hosted?
- When was a backup restore last tested?
- What happens, and who is told, if there is a breach? Serious personal data breaches must be reported to the ICO within 72 hours.
Getting help
If you already have an app built by someone else, our takeover review looks at what it runs on, the state of the code and dependencies, where the data lives and what it will cost to look after. You get the written review whether or not you go ahead. Start with the web application development page, or contact us.