Implementing Layered Security in an API

APIs are commonly used by business organizations for connecting different services and transferring data. Attackers attempt to exploit API vulnerabilities such as broken authentication and security misconfiguration for malicious purposes. Exposed APIs can become a major cause for the breach of sensitive data such as Personally Identifiable Information (PII) to the public. Hence, developers must use multiple security layers to avoid API exposure and data breaches.

Considering the scenario of an API that fetches the transactions of a company, developers and security experts can implement the following layer-based security for the API:

Layer One

Authorization & Authorization

The API validates the user to check whether the entity is authorized by the company. In this situation, the developers can use API Security, by which an exception will be returned if the user is not authorized or permitted. For example, the API may throw a “Company Not Found” exception. This helps the API developer identify any invalid company.

• Example: Using OAuth2 tokens, JWT validation, or API keys
• What it protects against: Unauthorized access attempts, credential stuffing

Layer Two

Query Validation

In this layer, middleware can be used by the API to provide a query plan by calling the data layer. The database layer declares a filter for the company ID before sending a request. Developers can include a security mechanism to return an exception such as “Unsafe Data Query” in the absence of such a filter.

• What it protects against: Authorization bypass bugs, missing access controls in business logic

Layer Three

Database-Level Security

In this layer, an SQL join must be used to query an SQL database using the data link layer based on API calls. This helps in ensuring that all the queries match the user responsible for the API call. Moreover, this verifies the user context, in contrast to its data stored by the SQL layer.

• Example: Every query automatically includes WHERE company_id = <authenticated_user_company>
• What it protects against: Logic errors in application code, SQL injection that bypasses app-level filters

Layer Four

Data Transformation

This layer creates a mapper layer that enables the conversion of all the database records into different user-visible models. This technique can be used to prevent sensitive data such as implementation details from the public or customers.

• Example: Internal model has password_hash, internal_id, db_metadata — external model only shows username, email, created_date
• What it protects against: Information disclosure, exposing internal architecture details

Layer Five

Response Filtering

The response filter of the API verifies the models that are generated by the mapper layer above. After the response filter declares that the records match the user calling that API, it allows the user to observe a specific account. This layer discards the data models without clearly flagging the account of a customer by double-checking the work of other layers.

• What it protects against: Edge cases, race conditions, bugs in earlier layers