At risk of gathering more attention (!), now that we know more about the context and threat model here (ie: the legitimate users are the likely attackers), are there other risk mitigating controls that you have / could have to reduce the risk to the business? Things that come to mind (in no particular order):
Alerting on suspicious requests, given that attackers are likely to get a few requests wrong before they find anything effective, ie: enumeration of APIs or parameters, repeated requests.. maybe also rate limiting to buy time for response teams!
Revertible transactions / information (eg: keeping transaction history for rollback), where other channels are used to gain assurance of requests (eg: face-to-face conversation, paper evidence). This is the 'bank refunds' model to protect customers when mistakes happen.
Multi-party authorisation, with (hopefully) more trustworthy people needing to approve sensitive changes, again using separate channels to gain assurance if required. You may want to specifically isolate sensitive approvals away from the attackable web app (depending on volume, this could even be manual via a database admin)
Developer / insider protection, separation of duties; ensuring those with access to the code (and thus most likely to find exploitable backend bugs) don't also have admin access to production, ensuring those who have admin access to the database (or state store) don't have the same motivation to manipulate it - this is one reason those jobs pay more, it puts their price up to be corrupted.
These are awesome suggestions, thank you very much.
The API has exponential throttling for the same IP or same user (it helped us check the DoS box). We log requests responded with 403 (forbidden). I'll talk to devops to see if they can set some sort of alert on it. Will definitelly be helpful.
Some actions are auditable and revertible. Not all, though, we can definitelly improve that.
Your third suggestion is excellent. We've been planning on integrating the app with the company's support platform, and having grants be handled by tickets flowing through a series of approvals. Gotta carefully secure that communication, though.
The last point is something we already do. Developers have no admin access in production.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
At risk of gathering more attention (!), now that we know more about the context and threat model here (ie: the legitimate users are the likely attackers), are there other risk mitigating controls that you have / could have to reduce the risk to the business? Things that come to mind (in no particular order):
These are awesome suggestions, thank you very much.
The API has exponential throttling for the same IP or same user (it helped us check the DoS box). We log requests responded with 403 (forbidden). I'll talk to devops to see if they can set some sort of alert on it. Will definitelly be helpful.
Some actions are auditable and revertible. Not all, though, we can definitelly improve that.
Your third suggestion is excellent. We've been planning on integrating the app with the company's support platform, and having grants be handled by tickets flowing through a series of approvals. Gotta carefully secure that communication, though.
The last point is something we already do. Developers have no admin access in production.