Security issues of exposing CRUD operations through a single API endpoint?

Question

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,

1. Can I document this as a security issue?
2. Is this only bad practice for REST APIs since they have a simplified structure? Does it affect SOAP API implementations as well?
3. 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.

Answer 1

There are different HTTP methods that can be used to preform those operations such as DELETE, PUT, GET and POST. Because of the way certain backend frameworks work, having different methods is a huge advantage as you can limit functionality according to the method being used.

What you have implemented is (I assume) using the POST method with an indicator of what operation to preform. From a security point of view, the design of this doesn't matter (unless exposing a security issue). What does matter is how you limit functionality and verify permissions. As long as that functionality is implemented properly, it is theoretically okay.

To answer your questions:

1. I would not consider what you have described a security issue, just bad design.
2. As I stated in 1, I would see this as bad design as it opens a lot of development issues.
3. I would recommend viewing the OWASP REST Security Cheat Sheet

Answer 2

This is only a design question, and without more context, I cannot even say whether it is bad design or not.

First of all is there any security problem? I can see no of them, provided you handle somewhere the authentication/authorization question if it matters in an acceptable way. Simply passing a used id in the request and testing that user id for authorizations is not.

Is it bad design? It depends. Your general architecture could only hardly process methods other than GET and PUT, in which case this would be a normal design. Or you could use on either end (client or server) a tool handling requests in that format - again no design problem.

On the other hand, if you have no special reason for this request format, and heavily use in that application or other that will be used by the same team (devs, maintainers or users) that would be used to a {GET|PUT|DELETE} /path/to/endpoint/id[/optional/params] format, or any other different format, it would be a design error not to follow the locally standard format.

Answer 3

There's no problem at all, and it looks like that you're messing things up, let me explain as I see it as an IT Architect.

First of all, if the API looks like - or even causing a deja vu - with the another vulnerable/hacked one - it does not mean that this new one is vulnerable. Of course, it's not an indulgence for a plaintext password as a HTTP GET parameter, but the design pattern is a show stopper when it looks like I've mentioned upstrings, no other links!

At second time, the key source of the vulnerabilities is the implementation - you can have a single endpoint service like the one in your question with an ironclad security embodied in it's code and server, so there will be thing to worry about. Or you can have a maximally isolated endpoints with separate identification realms e.t.c. - and a plaintext unfiltered exception thrown to the stdout and a script output with all the usernames, paths et cetera...

Finally, an attack needs a door to be opened, and it's a usage context for your service/API/web3 application - this is where the door is opened from. I saw ridiculously buggy API used with hardware-crypto-authenticator based industrial terminals and it did the trick! After the bugfixing the API was able to withstand the pentest, but even a buggy one was perfectly sealed by autonomous terminals and physically passed encryption keys.

Don't make a quick judgement just looking at one side of this triangle - a real answer to the question "is this paricular system secure?" may surprise you greatly ;)