Imagine an API where all CRUD operations are done through the same POST HTTP Request but with different "action" values from request body.
{
"action":"[create|read|update|delete]",
"user":"4",
.. [Other action specific parameters] ..
}
This looks bad from a design perspective, and might complicate things from a documentation/exposure perspective (handling unnecessary parameters for Read and Delete operations which only require an identifier).
Concerning security, I can see potential for possible Mass Assignment issues (E.g. Read only parameters initiated by CREATE being exposed through UPDATE), or Denial of Service (E.g. Excessive READ requests blocking other requests).
But I could not find a proper reference to point to that this is bad from a security perspective rather than a design/implementation perspective. For the latter also, the only reference I could find was from this stackoverflow question which only refers to RESTFul API development. Whether any guidelines recommend multiple endpoints for CRUD operations in SOAP API design is unclear. So,
- Can I document this as a security issue?
- Is this only bad practice for REST APIs since they have a simplified structure? Does it affect SOAP API implementations as well?
- Are there any references I could point to from either security or a design best practice point of view?
EDIT: Above is a generic implementation pattern I've seen from different clients I conduct security testing for, hence the ambiguity.