General Guidelines:
- Please obfuscate your code making it, at best, unobviously broken. Even if the code isn't important.
- Global state has been a known bad idea for forty years. Please don't do it.
- Corollary of either of the first two guidelines: Singletons are pure evil. Don't.
- Please think about encapsulate. That implies not shoving getters and setters all over the place. Also prefer not use implementation inheritance and avoid protected. Generally limit unnecessary access and implied implementation, even on larger scales.
- Please practice good dependency hygiene. Yeah it's not interesting, but turns out to be really important for a number of reasons.
- If you're doing layers of security, please do check each layer individually.
- Please don't give nulls a meaning. Throw an NPE.
Things that are wrong:
- "Postel's Law". Good for UI, but for machine interface you wont catch errors and differences fixing mistakes allows TOCTOU-style vulnerabilities.
- Given enough eyeballs, all bugs are shallow. Increasing the number of reviewers decreases the depth each one expends on the problem. It's the maximum depth which is crucial unless the problem is trivial in which case who cares.
- Vulnerabilities are the adversary's fault. Vulnerabilities are the fault of the party that decided to ship the faulty product.
Work: A "Vulnerability Engineer" in the Java SE Security team for Oracle Corporation UK Ltd.
Top advice: If I were you, I wouldn't be starting from here.
Toast advice: Look after the corners and the middle will look after itself.
