APIs secured by design

Introduction

Since the early design of computers, the main purpose has been to ingress, process, and egress data. Operating systems have ports opened for streams of data (under certain protocols) to be accessible for applications (code) to perform their functionalities. By design, security was not the initial priority; security arrived later when so many systems (applications) were already exchanging data across multiple platforms.

Antivirus, firewalls, gateways, web proxies, authorization validation, multifactor, and so many applications appeared to add the missing security layer, so systems can continue securely sharing data.

In the realm of your organization’s API platform, if your applications are exposed to the internet/public, hackers will do “API attacks”, and attempt to find a vulnerability; if they succeed in exploiting it, gain some access, and disrupt your entire API platform and your business. Hackers and Cybercriminals are engineering these attacks at a constant pace to discover a design flaw; to keep up, your organization must get advice from security experts and follow organizations; like Open Worldwide Application Security Project (OWASP, a nonprofit foundation that works to improve the security of software), who continuously updates its top 10 list for API Security Risks. Reading this list, some of them are the result of a software design phase that didn’t consider securely handling data. And all goes back to the design software phase.

Adding security to your applications helps, but API Attacks rely on direct access to public APIs to do any harm (if they use stolen credentials, the damage will be greater). As API Security is not part of your core business functions, your business team can’t keep up; the development team, confident that they have some security layer in place, may inadvertently design an application that is vulnerable. How to prevent this? One critical phase in any software design is the identification of non-functional requirements; where a specialized team can add a layer of security around your applications and other requirements (data models, volume, SLAs, etc.) that will set a strong foundation for your API platform.

From the OWASP top 10 APIs Security Risks, I will use API4:2023 Unrestricted Resource Consumption as inspiration for a couple of scenarios and provide some tips where non-functional requirements will help your organization have APIs secured by design.

Exposure of raw data

Don’t disclose raw data. Storing information in your systems (and sensitive data) may be a true necessity, but once your organization decides to store it, the challenge of keeping it safe is there. What non-functional requirement can you consider?

Scenario 1. You have the user’s date of birth stored in any of your systems, some attacker discovers an API method to request the user’s data. What should be in the API response?

• Raw value: Date of Birth (within any format).
• Mask values: replacing some values with a star (*) character.
• Calculated value: {adult: true, month: November} or {age:40} (limit the number of fields to avoid guessing the date of birth).
• Encrypted value: {dob: 15ABA0D…F}

Scenario 2. You have a unique identification (ID) for each customer, and it is internally used to get all data of your customer. A B2B application may need to have a subset of clients’ data stored inside their database, a unique ID is needed to assign an event/action to the same customer in both systems (or more systems). Later, the B2B application needs to post the event's outcomes for a specific customer back into your API.

How will you expose each customer’s ID in your API Platform to this external actor?

• Raw value
• Masked value: Only if this value is not needed when events come back to your organization.
• Calculated: Generate an alternative ID, that is used as a unique ID in that subset of data. And can be reversed to the customer's ID in a controlled manner to assign the event to the right customer.
• Encrypted value: {id: A269A0ED…F}

Things to consider:

• Raw values are still a risk, but information may be needed as it is one way to mitigate this risk:?expose raw values to just a known application(s) that are inside your organization network (IP Whitelist).
• It is possible to decrypt encrypted values if a strong method is not used.
• Calculated values must be designed so they cannot be used to query data within your system

Volume of information

The ability to store large amounts of data has become easy, scale-up is automatic, and this capacity of storage poses a risk, large volumes of data can be stolen if a flawed design allows it. Alternatively, by accepting large amounts of data in an uncontrolled manner, crippling your storage capacities (skyrocketing your cloud services billing).

Scenario 1. Your API exposes an operation over a resource “customer”; your API offers the option to include query parameters to narrow down the results or the opposite. If an Actor wants all your customer data, how must your API react?

• It needs to evaluate the volume an application can expose data; placing query limits makes sense to take into consideration; especially If the data will go outside your organization (public APIs).
• If query parameters are the only way to go, place some handrails, like defining a fixed number of parameters that allow for a controlled volume of data to be retrieved.
• One great way to control the amount of data is to narrow it to just one record, and if the query parameter brings more than one record, reply with the error message “bad request” (your API specs must describe this behavior), so a bad actor doing API Attacks will be discouraged of using this API attack.

Scenario 2. You allow posting/uploading files via a public API, and a bad Actor tries to exploit this functionality by saturating with all types of binary objects.

• Limit the amount, size, and type of document allowed by your APIs.
• Allow only this functionality to known applications that are inside your organization’s network.

Things to consider:

• Who will be able to get/post a large volume of data? This should be one of the first non-functional requirements to be defined for any API that exposes data; and for each that ingress data into your backend systems.
• Small execution timeout among internal components may disrupt an API Attack that is attempting to get a large amount of data. And when timeouts occur, trigger alerts and notifications. Always keep in consideration your API SLAs in your non-functional requirements.

Industry Applications

In general: Enable B2B applications to do business within your organization (API Platforms). Allow execution of business operations within handrails under SLAs and secure exchange of data.

Health: The patient’s subset data is being shared with the proper audience; each receives the necessary information to do their work: The family doctor will see some data, the pharmacist fulfilling prescriptions see another, and laboratories get another; lastly each can post/upload the data that is allowed to integrate into a patient’s record.

Retail: Enable seamless experience for customers buying online and in-store; while the customer's information is being kept safe and data is well integrated across stores and online.

Conclusion

Sharing information (data) among systems that trust each other, may make data security measures unnecessary, but new requirements arise, systems are added, data changes and platform communications changed; creating room for security flaws available to cybercriminals. If your organization has an API platform and changes are happening, then non-functional requirements are the way to always include API security measures in any enhancement. Lastly, follow security experts and organizations to be aware of the latest security threats to maintain your non-functional designs and a guaranteed way to have a secured API platform.

Takeaway: OWASP at https://owasp.org

ANNEX

B2B/B2C enabled by Mediation Pattern

Presentation layer:

After a security layer, Public/Internal APIs differentiate requests, these will adjust the operation and the response according to what is needed regarding data security safeguards.

Non-functional requirements will be taken care of:

• Identification of external/internal consumers.
• Validation of the request (operation, URI, query parameters, headers and credentials, body’s schema).
• Timeouts are based on the SLA/data each can receive.
• Internal headers injection, so mediator and internal components trust in the API requests the presentation layer allows to reach them.
• Response formatted accordingly, and removal of internal control headers.

Mediator layer:

Support operations (create, read, update, delete, etc.) over a resource (samples: Customer, Order, Employee, etc.).

Non-functional requirements will be taken care of:

• Internal headers will indicate additional security constraints to be applied to the operation/data requested: Raw data management, size/limits around data/records on response.
• Response formatted accordingly.
• SLA definition for response times while getting data.

System component layer:

Processing, System, and Backend Systems will execute operations over the exposed resources, using data received and aggregation/built a response.

Non-functional requirements will be taken care of:

• Trigger dedicated operations depending on the type of API Consumer (internal/external).
• Trigger management requirements over raw data and size.

Finally

For each layer, error responses may be different per type of API Consumer, like HTTP status code, and the response body may be manipulated.

• Sample: An API Attack provokes an error at one internal component, a 500 error is raised, and the body/headers expose internal code and/or have server fingerprints. The Public API may change the response from a "500 System Error" to "400 bad request", and no additional information is disclosed; so, the attacker is unaware of the outcome of his attack.

Separation of concerns

It is a principle used in programming to separate an application into units, with minimal overlapping between the functions of the individual units. In the Mediation pattern, each layer represents a unit with unique functions over the data and its flow.

Summary

The Mediation Patterns allow each of your components to focus on small tasks; implement specific security measures, like the identification of actors, and adjust behavior according to non-functional requirements.