They allow applications, services and systems to communicate with each other. They are used within websites, mobile applications, payment platforms, cloud services and many other technologies.

For example, a mobile application may make an API call to retrieve the users profile information.

However, they often contain sensitive information and important functions, so if not secured properly can allow exposure of data or users doing things they shouldn’t be able to do.

Therefore, API Security is an important part of developing modern applications.

In this article, we will look at some common API security issues, why they are important and how developers can reduce the risk.

1. What is API Security?

API Security is the set of practices, technologies and policies that are used to secure APIs.

This ensures:

• Only authorised users and applications can access secure endpoints.
• Users can only access the information they should be able to.
• Sensitive data is kept safe during transfer.
• Requests to the API are validated.
• Unusual or excessive activity can be spotted.
• APIs are configured securely.

API security should be considered during development.

2. Why is API Security Important?

APIs often provide a link between users, applications and backend services.

This means if there is a security issue with your API it can cause issues across different areas of your application.

Some common issues include:

• Sensitive Data Exposure – The API may return data that shouldn’t be available to the user.
• Broken Authentication – Poor authentication can allow unauthorised users to gain access to accounts.
• Broken Authorisation – Users can access resources for other users.
• Excessive Requests – Poor resource management can cause issues with availability of the application.
• Security Misconfiguration – Misconfigured settings can expose services or sensitive data.
• Third Party – The application may be using third party APIs.

The OWASP API Security Top 10 provides a good reference.

3. Common API Security Issues

3.1 Broken Object Level Authorization (BOLA)

This occurs when the API doesn’t validate if the user has access to a specific object.

For example, an application may allow users to view their profile using an endpoint which requires a user ID.

However, if the backend only checks if the user is logged in and doesn’t check if they are the owner of the profile, this could expose information.

How to prevent:

• Validate if the user owns the resource on the server side.
• Ensure all requests for secured objects are checked for permissions.
• Never trust client side IDs.
• Include authorisation checks during development.

Authentication is used to verify who a user or application is.

Poor authentication can leave your API vulnerable to account compromise.

Common issues include:

• Poor password policies.
• Poor token management.
• No Multi-Factor Authentication for sensitive accounts.
• Incorrect session management.
• Tokens are valid for too long.

How to prevent:

• Use standard authentication methods.
• Secure your authentication tokens.
• Ensure tokens expire after a certain time.
• Secure session management.
• Use Multi-Factor Authentication.

3.3 Broken Object Property Level Authorization

This occurs when an API returns or allows changes to properties for an object without checking if the user has permission.

For example, a profile endpoint may return internal account information which should only be seen by admins.

How to prevent:

• Only return the fields required.
• Validate the properties users can change.
• Add permissions to properties.
• Don’t automatically return whole objects from the database.

3.4 Unrestricted Resource Consumption

APIs use resources such as CPU, Memory, Storage and Bandwidth.

If you don’t restrict how much resources are being used, you can have excessive requests which may impact availability.

How to prevent:

• Rate limit.
• Limit how much data can be sent in a request.
• Pagination.
• Set appropriate timeouts.
• Monitor resource usage.

3.5 Broken Function Level Authorization

This occurs when users can access functions that should be restricted to other roles.

For example, a standard user shouldn’t automatically have access to admin functions.

How to prevent:

• Enforce permissions on the server.
• Implement Role Based Access Control.
• Check authorisation for sensitive functions.
• Test different user roles have the correct access.

3.6 Security Misconfiguration

Misconfigured APIs can cause unnecessary security risks.

Examples include:

• Debug information being exposed in production.
• Unnecessary endpoints enabled.
• Incorrect CORS configuration.
• No security headers.
• Too many permissions.

How to prevent:

• Check configurations in production.
• Disable any unnecessary services.
• Keep dependencies up to date.
• Don’t expose internal error details.
• Regularly check API security settings.

4. Authentication vs Authorisation

Authentication and authorisation are closely related but serve different purposes.

Authentication

• Verifies Identity Example: Who are you?
• Often uses passwords, tokens or MFA
• Happens before protected access is granted

Authorisation

• Determines Permissions Example: What can you access?
• User roles, policies, and permissions
• Determines which actions are allowed

For example, a user may successfully authenticate to an application but still be denied access to an administrator endpoint.

This is why both authentication and authorisation are necessary.

5. Best Practice

As a developer you can implement the following to improve API security:

• Use HTTPS: Protect data while it travels between clients and servers.
• Validate input: Check incoming data before processing it.
• Enforce authorisation: Verify permissions for every protected operation.
• Use secure authentication: Follow established authentication standards.
• Apply rate limiting: Reduce excessive or abusive requests.
• Protect sensitive information: Avoid returning unnecessary personal or internal data.
• Manage API keys securely: Do not expose secrets in public repositories or frontend code.
• Maintain an API inventory: Know which endpoints and versions are active.
• Monitor API activity: Record relevant security events.
• Update dependencies: Address known vulnerabilities in libraries and frameworks.

6. Testing

Testing should be done during development. Testing can include:

• Authentication.
• Authorisation.
• Validation.
• Rate limiting.
• Error handling.
• Dependencies and configurations.
• Different user roles.

As a developer you should also check the documentation for your API to make sure it is accurate.

Only test in systems you have permission to.

7. OWASP

The Open Worldwide Application Security Project publish guidelines to help developers understand security risks within their applications.

The OWASP API Security Top 10:2023 lists 10 important security issues for APIs:

• Broken Object Level Authorization.
• Broken Authentication.
• Broken Object Property Level Authorization.
• Unrestricted Resource Consumption.
• Broken Function Level Authorization.
• Unrestricted Access to Sensitive Business Flows.
• Server Side Request Forgery.
• Security Misconfiguration.
• Improper Inventory Management.
• Unsafe Consumption of APIs.

This is a good starting point for developers looking to improve their API security.

This isn’t an exhaustive list of all vulnerabilities.

8. Future of API Security

APIs will continue to be an important part of applications.

With the rise of microservices, cloud platforms, mobile applications and third party integrations, it is important to ensure you have secure communication between services.

Developers will need to focus on:

• Strong identity and access management.
• Automated security testing.
• Inventory management.
• Secure communication between services.
• Monitoring and anomaly detection.
• Securing sensitive business functions.

API security will continue to be an important responsibility for developers and security professionals.

Conclusion

APIs are an essential part of modern software, but can introduce security risks.

Poor authentication, broken authorisation, excessive resource usage and security misconfiguration can expose your application and sensitive data.

By following best practice and using resources like the OWASP API Security Top 10 you can create more secure and reliable APIs.

API security should never be an optional feature, it should be considered at all stages of application development.

References

OWASP API Security Project OWASP API Security Top 10 OWASP REST Security Cheat Sheet

However, organisations are using technology differently now:

• Employees are not connecting to systems from an office.
• Applications are using the cloud.
• Data is stored in many places.
• Services regularly interact with each other using the internet.

A secure network with trusted users is no longer enough to protect your organisation. You no longer trust the users or devices to connect to your network. This is where Zero Trust Security comes in.

Zero Trust Security ensures your company resources are secure by verifying users and devices. The principle is based around:

Never Trust, Always Verify

1. What is Zero Trust Security is a type of cybersecurity that ensures users, devices and applications are verified before they can gain access to company resources. Traditional security methods often use network security to allow users to connect to the internal network and access multiple systems.

However, with Zero Trust Security this is no longer the case. Even if a user is connected to the company network their identity, device and permissions will need to be considered.

For example if an employee is trying to access an internal application they will need to:

• Log into the application.
• Verify their identity.
• Check their device meets the security requirements.
• Check their permissions.
• Only allow access if they meet the security policies.

They will not automatically have access to everything. All requests will be checked against the security requirements.

2. Why is Zero Trust Important?

The network boundary has become more complex. Traditionally organisations would focus on securing their network from within the office. However now employees, applications and services are spread across multiple environments.

This causes some issues:

• Remote working – Employees regularly connect to company systems from home and public networks.
• Cloud Applications – Data is stored and applications are run across multiple cloud platforms.
• Password theft – Credentials can be stolen to allow unauthorised users to access company accounts.
• Insider threats – Employees or authorised users may accidentally expose information or misuse their privileges.
• Devices – Organisations must manage access from devices such as laptops, mobiles and servers.

We can no longer trust users to have access just because they are connecting from a certain network. Zero Trust looks at all access requests.

For example, if an employee is connecting to a company application from a managed laptop they may meet the security requirements. However, if they are connecting from an unknown device or there is suspicious activity during login further verification may be required or no access given. This means organisations have more control over who has access to the systems.

3. Zero Trust Principles

There are many security principles within Zero Trust. These help to prevent unnecessary access and increase security.

3.1 Never Trust, Always Verify

Probably the most well known principle of Zero Trust. Instead of trusting users to have access because they are connecting to an internal network all requests should be verified. This means the organisation can consider:

• User identity.
• Device identity.
• Authentication.
• Location & Context.
• Application/Resource.
• Security policies.

For example, even if the user has authenticated to their company account they may not have access to sensitive financial information. The system should check they have the correct permissions.

3.2 Least Privilege

Least Privilege means only giving users and services the necessary permissions. Giving users too many permissions can cause more damage if their account is compromised or accidentally.

• An administrator would have permissions to manage systems and configurations.
• A developer would have access to development environments.
• An analyst may only have view permissions to reports.

All these roles have different responsibilities so should have different access. If all employees had administrator access this would cause unnecessary risk. With Zero Trust you should be careful with permissions and ensure they are reviewed so users don’t have access to resources they don’t need.

3.3 Assume Breach

Zero Trust assumes organisations may have already had a breach or an attacker may gain access. This means organisations should not rely on one security boundary. Limiting access between systems, monitoring and preparing for possible incidents.

If one user account is compromised the attacker should not be able to access all systems. Limiting permissions and separating resources will help with this.

3.4 Continuous Verification

Authentication should not just be a one off process. Sometimes users may log in but their situation may have changed. For example their device may no longer meet company security policies or unusual activity may be detected. The organisation may want to verify further or deny access.

4. Zero Trust Architecture

Zero Trust Architecture is the framework organisations use to implement the security principles. This will depend on the infrastructure but generally will have some components:

• Identity Provider (IdP) – Manages user identities and authentication.
• Policy Engine – Verifies access requests and checks if they meet security policies.
• Policy Administrator – Takes action based on policy engine decisions.
• Policy Enforcement Point – Controls the connection between the user and resource.
• Monitoring – Capture relevant security events to help identify suspicious activity.

When a user tries to access a company resource the following will occur:

• User requests to access an application/resource.
• Identity provider verifies user.
• Device and context information is checked.
• Policy engine checks if request meets security policies.
• Policy administrator notifies enforcement point.
• Grant/Deny access.
• Monitor relevant activity.

The main thing to note is that the organisation will decide whether to grant the request based on the request. Depending on the technologies being used the architecture may look different but the principles will be the same.

5. Benefits of Zero Trust

Implementing Zero Trust can help improve a number of areas within an organisations security. Some key benefits include:

• Reduce unauthorised access – Users and devices will need to meet the security requirements to gain access to secured resources.
• Improved identity security – Authentication and identity management becomes more important.
• Better access control – Least Privilege means users can’t access systems and information they don’t need.
• Remote working – Employees can securely access company resources.
• Improved visibility – Monitoring will help organisations understand who is accessing resources and identify any suspicious activity.
• Reduce lateral movement – Separating systems and limiting access can make it harder for attackers to move between resources if their account/device is compromised.

Another key benefit is that Zero Trust can be implemented across different environments. Organisations may not need to rely on one internal network.

6. Challenges of Zero Trust

Whilst Zero Trust can help organisations become more secure it may not be easy to implement across the organisation. This can cause issues with the infrastructure, applications and processes. Some common issues include:

• Legacy systems – Older applications may not support modern authentication or identity based access.
• Complex Infrastructure – There may be multiple networks, cloud platforms and applications.
• Poor User Experience – Poorly designed verification can cause frustration for employees.
• Cost – Extra investment may be needed for identity platforms, monitoring and improving the infrastructure.
• Managing Policies – Policies may need to be updated as employees change roles, devices change and new applications are added.

It may be challenging to know where to start. Trying to implement Zero Trust across all systems can cause unnecessary disruption. It is best to implement it gradually. Start with key user accounts, sensitive information and critical applications. This will help organisations understand their infrastructure and make changes.

7. Best Practice

When implementing Zero Trust organisations should start by understanding what they need to protect and how users are currently accessing resources. Some key points to focus on include:

• Identify Key Resources – Understand what systems, applications and data are most important.
• Keep accurate records – Keep track of users, devices, applications and services.
• Strong Authentication – Ensure appropriate authentication methods are in place, especially for elevated accounts.
• Least Privilege – Ensure users only have access to the resources they need.
• Monitoring – Monitor activity around sensitive applications and company information.
• Separate – Don’t allow unnecessary access between environments.
• Review Permissions – Remove access if employees change roles.
• Incident Management – Have a process in place to manage security issues.
• Test Policies – Regularly test policies are working as intended.

This will help create a more controlled environment. Remember to regularly review Zero Trust

As requirements and infrastructure change.

8. Future of Zero Trust

As organisations move towards using cloud platforms, remote working and connected applications identity based security will still be an important aspect of cybersecurity. As organisations use more cloud native environments Zero Trust is becoming more relevant.

Applications and services may be interacting with other services across different cloud providers, networks and infrastructures. This makes traditional network boundaries less practical. Organisations should consider how to authenticate and authorise users, devices and services.

NIST have also released a practical guide titled SP 1800-35 in 2025 showing how organisations can implement Zero Trust Architecture using commercially available technologies. This can be a useful reference.

Overall, Zero Trust is not a product that can be installed to fix all security issues. It is an ongoing strategy that organisations need to review, manage identities, monitor and make changes to policies as their infrastructure changes.

9. Conclusion

Zero Trust is changing the way organisations secure their networks and information. Instead of trusting users and devices because they are connecting to an internal network they will be verified based on their identity, permissions and situation.

Principles such as Least Privilege, Continuous Verification and Assume Breach help to reduce unnecessary access and reduce damage from compromised accounts/devices.

Whilst there can be challenges with implementing Zero Trust, especially with complex/legacy infrastructure, implementing it gradually can help. As businesses move towards using more cloud services, remote working and distributed applications Zero Trust will remain an important part of securing modern IT environments.

References

• NIST SP 800-207 – Zero Trust Architecture: https://www.nist.gov/publications/zero-trust-architecture
• NIST SP 1800-35 – Implementing a Zero Trust Architecture: https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
• NIST – Zero Trust Networks: https://www.nist.gov/programs-projects/zero-trust-networks

When developing modern web applications with Next.js you often need to make decisions for user authentication and authorisation. To do this securely and avoid many common access control issues I created RBAC Session Auditor.

• Live Demo: https://auth.afthyir.co.uk/
• Source Code: https://github.com/afthyir/rbac-session-auditor

About RBAC Session Auditor

What is RBAC Session Auditor is a Role Based Access Control (RBAC) system for Next.js that is designed with security in mind. It ensures every request is validated against:

• An active Supabase login
• A Redis session whitelist.

If a request is not valid or doesn't have the correct permissions it will be instantly blocked and logged to a security audit.

Security Architecture

Role Enforcement in Edge Middleware There are three different roles set up for users in the application. These are enforced in Next.js Edge Middleware.

By enforcing these permissions at the edge, we can: Block any unauthorised requests before they can be processed in SSR or API. No way to manipulate roles using developer tools in the browser.

Instant Session Revocation

A common issue with stateless tokens (such as JWTs) is that once they are issued, they are valid until they expire. This means that if an account has been compromised or a users access needs to be revoked instantly, we can't wait for them to expire.

To combat this, RBAC Session Auditor requires that in addition to having a valid Supabase login, all sessions must also be on a Redis session whitelist. By removing a session ID from Redis, we can instantly revoke access to the application.

Fix Common Access Control Issues

Along with basic authentication, this project also helps to eliminate many high risk authorisation issues: BOLA (Broken Object Level Authorisation) - Prevents users from viewing or altering another user's resources by guessing or incrementing object IDs. Fail Closed - If there is an error, timeout or unexpected result when verifying, the request will be denied. Admin Routes - Any sensitive admin routes are completely separate to the client.

Security Audit Logging

To help with investigating any incidents, any denied access attempts will be automatically logged. This will include: Who made the request What route/resource they were trying to access When the request was made.

Tech Stack

• Next.js (App Router & Edge Middleware)
• TypeScript
• Tailwind CSS
• Supabase (Authentication)
• Redis (Session Store & Whitelist)

Try it out!

You can try out the role enforcement, session revocation and audit logging. Or take a look at the code in the repository:

• Live Demo: https://auth.afthyir.co.uk/
• Source Code: https://github.com/afthyir/rbac-session-auditor

Created by: Afthy Irshath (@afthyir)