Insights / Checklist / Custom Application Development
ChecklistSecurity basics for custom applications
Security is cheaper to design in than to add later. Use this checklist to control access, protect data and keep the libraries your application depends on up to date.
Security is cheaper to design in than to add later. A permission model planned on day one costs a few hours of thought. Retrofitting one into an application already used by hundreds of people can take months, and every week in between is a week of exposure.
This checklist is written for leaders who commission custom applications and want to ask the right questions of their development team or partner. It does not replace a specialist security review for high-risk systems, but it covers the basics that prevent most common problems.
Control access
Authenticate users and give only needed permissions. Most security incidents involve someone gaining access they should not have, whether through a stolen password, an old account nobody switched off or a role with far wider rights than the job required.
- Users sign in through your organisation’s identity provider where possible, rather than separate passwords.
- Multi-factor authentication is required, at least for administrators and remote access.
- Roles are defined by job, and each role has only the permissions it needs.
- Every request is checked on the server, not just hidden in the user interface.
- Accounts are disabled automatically when people leave or change roles.
- Administrator rights are held by a small, named group and reviewed every quarter.
Hiding a button is not security
A common flaw is to hide a feature from users who should not have it while leaving the underlying function open. Ask your team to confirm that every action is checked on the server against the user’s permissions.
Protect data
Encrypt sensitive data and log access. Start by knowing what you hold. Personal details, financial records, health information and commercially sensitive data each carry different legal and reputational risks. An application that stores none of them needs lighter controls than one that stores all four.
- A simple data inventory lists what sensitive data the application holds and why.
- All traffic is encrypted in transit, with no exceptions for internal connections.
- Sensitive data is encrypted at rest, including in backups.
- Passwords, keys and connection details are kept in a secrets store, never in code.
- Access to sensitive records is logged with who, what and when.
- Logs are kept somewhere the application’s own administrators cannot alter.
- Data you no longer need is deleted on a defined schedule.
Collect less where you can. Every field of personal data you do not store is one you cannot lose. A typical example is a booking system that keeps full dates of birth when it only needs to confirm a customer is over eighteen; storing a simple yes or no removes the risk entirely.
Keep dependencies updated
Check libraries and fix known vulnerabilities. Modern applications are built largely from open-source and third-party components. That is efficient, but it means a flaw discovered in a widely used library can affect your application overnight, even though your own code has not changed.
- An automated tool scans dependencies for known vulnerabilities on every build.
- Critical vulnerabilities have a target fix time, for example within days, and it is tracked.
- Unused libraries are removed rather than left in place.
- Hosting platforms, operating systems and databases are patched on a regular schedule.
- Someone is named as responsible for watching security advisories for the main components.
Build security into delivery
The checks above only work if they happen continuously. Security that depends on a penetration test once a year will always be behind. Build the basics into how the team delivers software, so that every change is checked as a matter of routine.
- Code changes are reviewed by a second developer before release.
- Automated tests include checks for common flaws such as injection and broken access control.
- An independent security test is run before launch and after major changes.
- There is a written plan for what to do if a breach is suspected, including who to call.
Trade-offs and where to start
Stronger security sometimes adds friction. Multi-factor sign-in takes a few seconds longer, tighter permissions mean more requests for access, and patching takes time from feature work. The aim is proportion: heavier controls where the data or the function is sensitive, lighter ones elsewhere.
Ask your development team or partner to go through this checklist with you for your most important custom application. Mark each item as done, partly done or missing. The missing items in access control and dependency scanning are usually the quickest to fix and remove the most risk.
Source: Intelliversal analysis.
