The top comments here are really harping on things that aren't necessarily actionable (with the exception of backups, but I'd split hairs on whether that's a se

The top comments here are really harping on things that aren't necessarily actionable (with the exception of backups, but I'd split hairs on whether that's a security mistake or a business process mistake). I interpret your question to mean security mistakes that have an actionable basis. The most common security mistake I see is API authorization errors, in the abstract. More specifically, I see this manifest itself reliably as insecure direct object references. Nearly every security assessment I have ever been on has had an API where you can slightly alter a parameter value and bypass authorization controls altogether to access another user's account (or whatever other state-changing action you can think of in the context of their session). In an era where just about everyone knows what SQLi and XSS are, actual logic errors fly right under the radar and authorization controls are not implemented universally. To be even more specific - do you have a microservice architecture? Have you tested that every backend service has the same authorization controls in place? When was the last time you tested this? Put your backend services behind a common access policy (you can use something like Kong for this), and make sure that you parameterize all calls between services, because someone can and will access your privileged services through a less privileged service using an unexpected or undocumented call. For that matter, use internal access policies to discriminate between more and less privileged services. It doesn't matter if you have a DMZ and firewall open IP traffic if you give a user-facing service access to a more privileged service - users can hop between them. And when you deprecate an internal legacy API, actually remove it from being accessible by other services. This is probably still the number one way that people find really serious vulnerabilities in Facebook. I've seen cases where user input was used by Service A to directly query Database B using fallback API C, giving the user de facto arbitrary read access to the entire table. Database B is always firewalled to outside internet traffic in these scenarios, but Service A gets a free pass to access internal resources and voila. It's fairly straightforward to classify specific technical issues, but if your APIs for various backend services are not properly set up with authorization controls you open the door to remote code execution, command injection, server-side request forgery...it's pretty bad. And it's largely unknown by developers because they are hyper-focused on common web vulnerabilities, which frankly are mostly solved by using the right libraries these days.