The questions to answer before the first line of code: what data the tool touches, who can reach it, where it lives, and what happens if it is compromised.
Security decisions are cheap before you build and expensive afterwards. The following questions take an afternoon and will change what you build. What data does the tool actually touch? Is protected health information involved, which brings obligations that have nothing to do with your preferences? Is personnel information involved, which brings different ones? Does it require authentication at all, and who genuinely should have access rather than who would find it convenient? Then the practical side. Where is the data stored, and in whose account? Are secrets and API keys kept out of the code and out of shared drives? Are logs retained, and for how long? Is multi-factor authentication appropriate here, which it usually is the moment real data is involved? Finally the two questions people skip. What happens if the tool is compromised — what could someone reach through it, and how would you know? And what happens if the hosting service fails, changes its pricing, or closes? A free tier is a business decision somebody else gets to revisit. None of this makes internal building unwise. It makes the difference between a tool your IT department can live with and one they have to shut down.
If you read one thing on this subject, read this.
The ten most common categories of web application security risk, maintained by the OWASP Foundation, a nonprofit application-security organisation.
Why it matters
If your tool is on the web, this is the list of ways it is most likely to be broken into. It is written for developers but the categories are readable by anyone.
The federal framework of practices for developing software securely.
Why it matters
More than a small internal tool needs, but the right reference once a project has outgrown casual development.
Principles for software that is safe by default.
Why it matters
Worth reading before you decide which defaults your own tool will ship with.
The Hub's track on cybersecurity as operational readiness.
Why it matters
Anything you build sits inside the department's security posture, not beside it.
Everything above was published by someone else, and is here because it is the clearest treatment of the subject we could find and verify. The Hub’s own guide to this topic is still being written. If you know a better source than the ones listed, that is worth telling us before it is.
Send a note