Deadly Sins of Secure Coding
Pride — We’re already behind X, it is not possible to attack this application.
It’s great to have trust boundaries. It’s great to be inside a trusted network or being behind a well configured security device. It’s one of the core elements of Secure By Design. But it’s never enough to making everything secure. With a layered security design, vulnerabilities can be covered off by generic prevention, it’s always better to have additional prevention logic as the layers go deeper. Remember configurations can change, systems may fall, new attacks are invented everyday and it’s really easy to passing away one of the layers. Having a layered security perspective both on outside of the application and inside of it can prevent deadly flaws.
Gluttony — We’ve implemented our own framework. It’s really hard to attack.
Over engineering is the obesity of the systems. It does not only kills manageability over time it also damages security preventions. The popular tools that are being developed of course have vulnerabilities but the one you’re building has more for sure. Combining functionality and security is often quite a challenge and generally that custom/clever tools, fail worse. Being understandable & manageable also means being more defendable. The more the code is tested the more bugs appear. Do not fall in the pitfall of no tests — no bugs
Relying on Assumptions & Happy Paths — It’s an edge case.
One of the primary goals of attackers is to render applications inoperable. If you have an unstable product, it can turn into a good mine for attackers. For example, if your application crashes with a specific HTTP request / payload, the attacker can make your systems inoperable by constantly repeating this request. This is sometimes caused by an incorrectly formatted JSON, or sometimes by a database query without type checking. Validating before doing anything takes a critical role here.
Obscurity — How will they know, to attack here?
How can anyone know, how our program works? How can they know our top secret key? How can they learn our business logic anyway? They will know. They can learn. They will use the techniques that you don’t know. Just don’t assume anything on the knowledge of the attackers. Always assume they gained access to somewhere and then what is our prevention. Security can only be implemented by secure layers on complex systems. Never ever rely on obscurity.
Blame — It’s your fault!
It is very difficult to manage security measures in organizations where employees are constantly blamed for their mistakes. It’s really really easy to keep secrets from management on software development. Especially on crowded organizations, blaming may be the root cause of the uncovered software bugs / security flaws. Culture & feelings takes a deep role on the quality and security of software.
