OWASP API Security Top 10 vulnerabilities 2023

API Security Do's and Don'ts

1. Don't trust input data for an API and do validate all inputs.
2. Ensure you understand security and keep sensitive data out of code.
3. Don't hardcode keys/tokens
4. Don't reveal useful info in error messages.
5. Don't have hidden/unadvertised features.
6. Don't filter data in UI - control at app level
7. Don't confuse authentication and authorization
8. Always use API gateways to control access and traffic
9. Do require API documentation.
10. Do expect users/hackers to find and use undocumented endpoints
11. Do continuous testing - attack simulation, test configs, fuzzing, injections
12. 
    

OWASP API Security Top 10 Vulnerabilities 2023

1. API-1:2023 - Broken Object Level Authorization: BOLA is still the leading vulnerability that plagues APIs. When data objects do not have sufficient access controls in place, resources can be accessed by unauthorized users.
2. API-2:2023 - Broken Authentication  Broken Authentication contains all vulnerabilities associated with authentication. This section includes weak passwords, JSON Web Token (JWT) misconfigurations, and insecure lockout mechanisms.
3. API-3:2023 - Broken Object Property Level Authorization: BOPLA is the combination of Excessive Data Exposure and Mass Assignment. An application should have sufficient access controls to prevent a user from altering sensitive data object properties.
4. API-4:2023 - Unrestricted Resource Consumption: APIs have technical and financial costs per request. If an API does not have sufficient controls in place then there will be a negative impact on the API provider.
5. API-5:2023 - Broken Function Level Authorization: This vulnerability is present if there are insufficient access controls in place between different user groups to perform sensitive actions.
6. API-6:2023 - Unrestricted Access to Sensitive Business Flows: Unrestricted Access to Sensitive Business Flows represents the risk of an attacker being able to identify and exploit API-driven workflows.
7. API-7:2023 - Server-Side Request Forgery: Server Side Request Forgery is a vulnerability that takes place when a user can control the remote resources retrieved by an application.
8. API-8:2023 - Security Misconfiguration: Security Misconfiguration represents a catch-all for many vulnerabilities related to the systems that host APIs.
9. API-9:2023 - Improper Inventory Management: Improper Inventory Management represents the risks involved with exposing non-production and unsupported API versions.
10. API-10:2023 - Unsafe Consumption of APIs: Unsafe Consumption of APIs is the only item on the top ten list that focuses less on the risks of being an API provider and more on the API consumer.

Broken Object Level Authorization(BOLA): 

Problem statement: Data objects do not have sufficient access controls in place and resources can be accessed by unauthorized users.

Example:

The application offers typical CRUD endpoints: 

• GET /people/ with no argument retrieves a list of all users.
• PUT /people/{ID} with a JSON record updates an existing user with new information.
• POST /people/ with a JSON record to add a new user.
• GET /people/{ID} to retrieve a user by Id.
• DELETE /people/{ID} deletes a user.

The hacker can change the Id in GET method and retrieve the details of another user without proper authorization. This problem can be solved by performing the pre-authorization check before providing the requested information.

There is should be different permissions for read operations, insert and update operations and delete is only admin users. Depending on the use case needs, provide fine-grained object-level authorization.

Solution: 

• Implement object-level authorization checks correctly within the API.
• Narrow down the object-level authorization for a specific role. Do not use a single generic role for all end points.

package dev.katha.library.service;

@Path("/user")
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("GENERIC_USER_API_ACCESS")
public class UserResource {

    private final UserDAO userDAO;

    public UserResource(UserDAO userDAO) {
        this.userDAO = userDAO;
    }

    @POST
    @UnitOfWork
    @RolesAllowed("ADMIN")
    public User createUser(@Valid User user) {
        return userDAO.create(user);
    }

    @PUT
    @Path("/{userId}")
    @UnitOfWork
    @RolesAllowed("ADMIN")
    public User updateUser(@Valid User user) {
        return userDAO.update(user);
    }

    @GET
    @Path("/{userId}")
    @UnitOfWork
    public User getUser(@PathParam("userId") OptionalLong userId) {
        return findSafely(userId.orElseThrow(() -> new BadRequestException("user ID is required")));
    }

    @DELETE
    @Path("/{userId}")
    @UnitOfWork
    @RolesAllowed("ADMIN")
    public User deleteUser(@PathParam("userId") OptionalLong userId) {
        return userDAO.deleteById(userId.orElseThrow(() -> new BadRequestException("user ID is required")));
    }

}

References: 

1. https://university.apisec.ai/products/api-security-fundamental
2. https://www.stackhawk.com/blog/understanding-and-protecting-against-api1-broken-object-level-authorization/
3. https://www.stackhawk.com/blog/java-broken-object-level-authorization-guide-examples-and-prevention/
4. https://www.veracode.com/security/java/cwe-639