design
4 articles with this tag
4 common security mistakes: default settings, forgotten services, missing monitoring and over-trusted input validation
Incidents come from a small set of recurring patterns, and the patterns are clearer sorted by belief than by technology. Four of them: defaults must be safe (nothing was configured), unused things must be harmless (nothing was closed), we would notice (nothing is observable), and validated input must be safe (too much was delegated to the input). None of these needs deep technical knowledge to fix — they need a habit of checking. Here is what to look at for each.
Insecure deserialization: the risk of letting external data choose the object type, and how to prevent it
The danger in deserialization is not that bad values arrive; it is that some formats let external data decide which type of object to construct. So the damage does not stop at corrupted data — OWASP lists denial of service, access control bypass and remote code execution. Two defenses: switch to a pure data format so nothing chooses types for you, and sign serialized messages so unsigned ones are never restored. And some mechanisms cannot be made safe by configuration at all; the only fix is not using them.
Password reset design flaws: 5 ways accounts get taken over despite strong login, and how to fix them
A reset flow is a mechanism for letting someone who does not know the password set a new one — which makes it an authentication path in its own right. Harden the login all you like: if reset is weak, reset is your real authentication strength. Five failure shapes: guessable tokens, tokens that never expire, links that live on in a mailbox, links whose destination can be set from outside (Host header), and responses that reveal whether an account exists. The key implementation step is separating what the guidance requires from the numbers it leaves to you.
Rate limiting and abuse control: designing limits that stop brute force and runaway costs
Rate limiting usually fails not because the limit was too loose but because the wrong question was asked. Three questions: who you count (IP can be forged and is shared by real users, so identity comes first), what you count (requests alone miss expensive single operations — cost, size, record counts), and what happens at the ceiling (blunt lockout is a denial of service against legitimate users). NIST caps consecutive failures at 100 and asks for delays and CAPTCHA instead of shutting people out; OWASP includes third-party spending limits, the final control against financial damage.