How do you design REST API security policies and roles for different users and groups?

It's a good idea to focus on the data - not functionality. Determine what's being sent or returned regardless of how it's gathered by the server. If a report is being returned, name the endpoint "report" as opposed to "generateReport" or similar.

Another very important aspect of the resources and operations are the paths and parameters. If you have a department with employees you might have end points like "/dept/<id>" and "/dept/<id>/employees" and so on. Plus, parameters for filtering, searching, sorting, etc. Using OpenAPI to design your API can lead to a lot of reuse and generated code. Tools like Swagger, Postman, Insomnia, etc. can be a huge help here.

Use a resource structure that considers collections of data and use the built in HTTP verbs. Examples: Create a report: POST /reports (note that this is plural because you are creating a new report in the collection of reports) Retrieve a report: GET /reports/{reportId}

Try https://www.openpolicyagent.org/docs/latest/rest-api/ Open Policy Agent is open source and can be used for a lot more than REST API's but this could be a solution.

When designing the API, use PUT to modify and DELETE to remove existing entities. Many APIs use POST for those functionalities which is not preferable. The HTTP verbs exist for a purpose. Although one may use POST for everything but a properly used verb not just make the intension clear but also force a more consistent URL design. For example: Instead of: POST /modifyFullname payload: {id, fullname} Use: PUT /{id}/fullname payload: {fullname}

One of the way.. use roles defined in cloud systems across your application. Jwt /Outh 2.0 token carrying role info before it allows user to access resources based on their roles. for example Azures RBAC solution : https://learn.microsoft.com/en-us/azure/role-based-access-control/overview

In situations where a superuser with full permissions is necessary, avoid creating a "super" role or user. Assign all roles to a super user account instead. Assess the necessity of a super user in production; it is generally unnecessary.

Many great tools like Postman, Swagger and Insomnia help define your OpenAPI spec for your RESTful API. They can generate the requests and display all of the data sent/received. Also, they can often generate mock servers and allow for a variety of methods of testing and automation.

Many developers who implement REST API that gets called from web pages assume that the data on the displayed page is validated and per business rules. Due to this, they ignore revalidating the input in their POST APIs, creating a major hole in the security of the application. For example, let's say a page displays a PII message to a user. The displayed page contains a message-id that the user is entitled to respond to. If the message-Id is not validated on the response creation REST API, it creates a security issue because REST API requests on the web can be made irrespective of whether the page is displayed. Bad actors can and will call the REST API for response creation with different message ids and spam users.

Use HTTPS to encrypt data in transit, and consider additional security measures like rate limiting, IP whitelisting, and input validation to protect the API from attacks.