- Validate ALL data that comes from external sources, even if you think it could not possibly be changed unexpectedly. External sources includes things like user input, configration and session files, and even things like dynamic libraries if you care enough.
- Sending data to an external system that processes commands, including destructive ones like DROP DATABASE? Verify what you're sending doesn't contain commands you don't want to run, each time, every time.
- If you are programming in C or derived, and using expressions that will be involved in array indices or pointer arithmetic, make sure the expression falls within acceptable range before using the resultant data. Since NULL or 0 is an invalid pointer value, it shouldn't ever reach the code that tries to access pointers.
- Should a sensitive function only be called from certain other functions? Should a sensitive variable only be modified/accessed from certain other functions? Enforce that.
- Someone will eventually find anything that's not documented, so don't rely on that for security. Don't expose an interface (especially not through any network accessible method) without an authentication or verification mechanism if it's not OK for it to be 100% public.
- Define everything. A function call should never have an unexpected result. Invalid inputs should cause the function to return errors or throw exceptions.
Telling people to "validate all data" is like telling them "not to have security bugs". It's not helpful advice. Validate for what? Length? SQL metacharacters? Javascript notation? HTML? Authentication? Concurrent submission? The list of things to consider is essentially a list of practically all vulnerabilities.
The point isn't that you shouldn't validate data. It's that telling developers to validate data doesn't help them. It begs the question of "how" to validate data, and the answer to that question is so big that it encompasses most of software security. Meanwhile, left to their own devices after that one instruction, developers come up with silly input validation schemes, like password fields that don't accept SQL metacharacters.
While hard to apply, the correct answer is pretty obvious: identify the invariants of your system, and make sure your inputs abide those invariants. To do this, there are two complementary approaches: you can parse your input into something intelligible and safe for your system, or you can reject invalid input.
The hard part is identifying the invariants of your system. But (and I know I'll sound like Dijkstra), that hard part is also the minimum bar. If you don't know what it takes for your system to behave correctly, how can you hope to build a correct (and therefore secure) system to begin with?
Some people love to say "don't roll your own crypto", with the strong implication that whoever is trying to it is not competent enough. Well, the same applies to any server exposed to the internet, any moderately interactive website, any network library, any video decoder, any compiler… all those things have the potential to go catastrophically wrong in the face of hostile input, and therefore should be held to similarly high standards.
Here's my advice:
1. Make sure you understand invariants, and why they matter.
2. If you don't, train yourself. It may take years.
3. Validate your inputs (but you already know that by now).
Not helpful? Sorry pal, programming takes time to learn, and I don't have the time to teach.
Security is mutli-faceted, so it's hard to know where to start. I like to help people begin by getting them to learn the fundamentals. A lot of security training is changing your mindset (perspective) on situations.
Two books I like to start this process:
* Threat modeling by Adam Shostack
* CISSP all in one handbook by Shon Harris
You don't need to get a CISSP cert, but the resources and education are generally applicable in most situations.
If you're looking for something more practically related to securing the code you write, the OWASP Top 10 (and OWASP in general) is probably the best place to start. Many modern frameworks like Spring have lots of nice security features baked in, but I've still seen plenty of low hanging Top 10 vulnerabilities in Spring apps -- most often caused by simply failing to use allowlist (formerly known as whitelist) validation on key inputs.
It is astonishing how often people neglect basic programming best practices (input validation, error handling, logging, access control) which in turn leads to security vulnerabilities. My theory is this is caused moreso by Agile Management forcing developers to cut corners, rather than just developers being ignorant/lazy.
Threat modeling can be a good practice to learn, because it gets you into the habit of thinking about how you could hack each new thing you're developing.
I dont think the CISSP is a good recommendation for this person's case, unless they plan on becoming a cyber security manager.
That's not my point suggesting CISSP. The book I recommended takes the reader through the different OSI layers for networking and security, a basic intro to threat modeling, and other stuff that is fundamental to security. One can always skip the managerial stuff, but it doesn't mean the CISSP book is not a good recommendation.
Also, having a developer understand the value and need for code security from the perspective of a security person is important to the overall success of an infosec program. Otherwise both engineering and infosec are going to be grating on each other.
- Sending data to an external system that processes commands, including destructive ones like DROP DATABASE? Verify what you're sending doesn't contain commands you don't want to run, each time, every time.
- If you are programming in C or derived, and using expressions that will be involved in array indices or pointer arithmetic, make sure the expression falls within acceptable range before using the resultant data. Since NULL or 0 is an invalid pointer value, it shouldn't ever reach the code that tries to access pointers.
- Should a sensitive function only be called from certain other functions? Should a sensitive variable only be modified/accessed from certain other functions? Enforce that.
- Someone will eventually find anything that's not documented, so don't rely on that for security. Don't expose an interface (especially not through any network accessible method) without an authentication or verification mechanism if it's not OK for it to be 100% public.
- Define everything. A function call should never have an unexpected result. Invalid inputs should cause the function to return errors or throw exceptions.
The above is a good percentage of it I think.