Probably Are Gonna Need It: Application Security Edition

This is a great list.

I think one of the hardest things to add after the fact are security headers. Once marketing is involved with an app's marketing site, it's going to be hard to add them in later. So I add them from day one, ace the Mozilla Observatory thing, and then if marketing needs something special, we can always deal with it then. Usually the result is something more secure, but sometimes turning off a flag for a single page is fine.

If it's the style of app where the backend is basically just a JSON API + workers, I like to follow JSON API[0] but I always add the `meta` and `errors` fields, even if it's just an empty dict, but usually there is something meta, like the latest versions of the client and server or a rate limit use + available combo. It makes writing clients easier. It also has knock-on effects, for example a delete request never gets a 204 NO CONTENT, since there is always content!

Once you get a consistent API the frontend just snaps together. Every now and then you may have to deviate a bit for performance or third-party reasons, but it's fine.

[0] jsonapi.org

I really like Jacob's suggestion to set up the "restore a copy of the production database to staging" script to use an allow-list of columns, rather than a deny-list.

It's so, so easy for PII and other sensitive data to end up copied to a staging environment, which has a higher chance of shipping a security vulnerability than the production environment does (plus exposes data to staff within an organization).

Strictly allow-listing columns from the start seems like a great way to minimize accidental leaks.

Get your AuthZ design right early on, or you’ll forever be plagued with APIs that fail open or aren’t protected, and it’s so very hard to change later on.

The best advice I’ve seen on this: https://research.nccgroup.com/2020/04/21/code-patterns-for-a...

One more thing to have, which seems obvious, but is also worth mentioning here: a Security Configuration Guide.

Basically, one guide that explains all the security features, how they work, when they should be used, associated configuration settings, what defaults are, what other possible values are, known gotchas, how to verify security features are working correctly, which ports and protocols are used and when they're used (so that a firewall admin can setup accordingly), etc.

Password hashing. Because you’re not storing clear text passwords, it can be tricky to upgrade later if you’ve chosen something bad like md5. You either have to force your entire user base to reset, or you do an over-time migration when people login, which will always leave some not upgraded.

Are there good security checklists for (1) personal security to protect one from hacking, identity theft, etc. and (2) businesses that have online services but aren't as tech savvy as a large tech giant that has huge security teams etc.

Using well known tools is a double edged sword. On the one hand security issues are often found fast and fixed fast. On the other hand they are also exploited fast and en masse.

I have been building websites professionally for nearly two decades. In that time I have seen major attacks against a number of sites I worked on. They were ALL exploits in up to date frameworks/applications found by bots scanning for known vulnerabilities. In order of severity Wordpress, Django, osCommerce; Django was actually the most recent.

I’ve never had a custom built app compromised. Unless you’re some major player, no one wants to take the time to find flaws in your snowflake (outside query injection and the other common things you should know to protect against with experience). They find a flaw in a framework or library and then try to apply the known flaw everywhere.

Should every site be a snowflake? Surely not, not every developer is competent enough to build safe applications. Does it come with major upsides? Absolutely.

I love this. It’s such an uphill battle sometimes to explain how small things will save so much time and pain later on but people will cling to YAGNI as a reason to ignore everything. Maddening at times.

I feel SSO should also be table stakes. Why even bother implementing your own account management if you can just use Keycloak or something even simpler to do it for you. This way your users can easily connect your app to whatever identity provider they are using.

> it’s nearly impossible to retrofit mitigations for spam, harassment, or abuse

... why?

It is bad enough that I have had to apply “application-layer” security to systemd in order to ensure that it “behaves”.