Secure APIs : Quick bites for APIs developers

What is API security?

• API security incidents are very costly for organisations. Security breaches can incur big penalties, while exposing vulnerable user flows allows hackers to abuse our business model, resulting in a potential loss of income and loss of reputation.
• Every input parameter in an API represents an attack vector, including URL query and path parameters, request payloads, and headers.
• Security by design is an approach that encourages us to shift left our API security strategy. With security by design, we apply security considerations from the design stage of our API development process.
• We can tackle many security vulnerabilities in the design, for example by exposing safe user flows, constraining user input, and by not exposing server-side properties in user input.
• Security by design encourages us to use secure implementation strategies, such as parametrising all database queries and avoiding mass assignment.
• We must continuously test our APIs to detect vulnerabilities, and we must automate as much of the testing process as possible.
• Secure architectural solutions such as deploying databases to private networks, using robust API gateways, and enforcing strict firewall policies, play a major role in API security.
• We must constantly monitor our APIs and run real time analysis of user activity to detect malicious behaviour and react to it timely.
• The growing number of APIs and connected IoT devices, the increasing complexity of APIs, and the emergence of Generative AI present unique new challenges in the current space of API security.

Aligning API security with your organisation

• Your API security journey begins with an evaluation of your API security posture. Organisations mature in API security have:Data inventory, i.e. they know what sensitive data they expose and where.Attack surface map, i.e. they know all the endpoints available on their APIs.Authentication and authorisation following best practices and standards like OAuth, OIDC, and JWTs.Robust access controls ensure users can’t get their hands on the wrong data. Secure implementation ensuring strict compliance with the API specification.Automated security testing using design-testing tools, fuzzy testers, and custom test suites.Risk analysis allows us to prioritise known vulnerabilities quickly.Incident detection that gives real-time visibility over suspicious user behaviour and security incidents.Incident response plans mean we know what to do when an incident happens.Continuous training to raise awareness about API security vulnerabilities.
• Threat modelling is a great exercise to get a holistic view of your API vulnerabilities and foster team collaboration.
• Good threat models answer the following questions from the Threat Modelling Manifesto:What are we working on?What can go wrong?What are we doing to do about it?Did we do a good enough job?
• To address the Threat Modelling Manifesto’s questions, we break down threat modelling into the following steps: Application decomposition Threat identification and ranking Response and mitigations Review and validation
• We use methodologies like STRIDE to model threats. STRIDE identifies the following threat categories:Spoofing: risk of stealing user credentials.Tampering: risk of performing unintended updates on our data.Repudiation: risk of not being able to detect malicious activity.Information Disclosure: risk of leaking sensitive data. Denial of Service: risk of system unavailability.Elevation of Privileges: risk of an attacker assuming admin privileges.
• The best way to start tackling API security is by picking low-hanging fruits like mapping out your attack surface, fixing your API documentation, or adopting authentication and authorisation standards.
• An API security program is an outline of your API security strategy and how you implement it.
• You need buy-in from your organisation to push forward your API security program:Get feedback from your stakeholders to encourage their involvement.Create metrics that show how your organisation benefits from this.
• To prepare for an API security audit, ensure you can answer detailed questions about your security posture. You must show awareness of current technical debt and commitment to address it.

API security principles

• Shift-left security is a paradigm that encourages us to address vulnerabilities at every stage of the software development life cycle (SDLC).
• Tackling security early allows us to build security into our APIs. Tackling security at the end bolts security onto our APIs, resulting in more vulnerable applications.
• Security by design enables shifting left on security by tackling vulnerabilities from our software’s design stage.
• When we apply security by design to our APIs, we are less likely to find major vulnerabilities at the end of the SDLC, allowing us to release faster and with more confidence.
• The Zero Trust Security model encourages us to remove trust from our systems and validate all traffic regardless of its origin.
• Zero Trust APIs validate data across all flows, including third-party APIs, our own databases, internal services, the request and the response flows.
• There is no such thing as an internal API. Zero Trust security means applying the same level of security to all our APIs.
• Bad API documentation or lack thereof means we don’t know how many APIs we have or how they work.
• API sprawling is the proliferation of duplicated and undocumented APIs. It includes:Shadow APIs: undocumented APIs released “under the radar” with little or no checks.Zombie APIs: deprecated API versions that we forgot to retire.Ghost APIs: APIs exposed by our third-party libraries or systems.
• API catalogs help us fight API sprawl by facilitating API discovery.
• To shift left on API security, begin by assessing vulnerabilities during the design stage. Tackle security at every stage of the SDLC and address vulnerabilities when tests fail before moving on.

Top API authentication and authorisation vulnerabilities

• The OWASP top 10 API security vulnerabilities is a list of the most common API threats published by the Open Worldwide Application Security Project (OWASP).
• Broken object level authorisation (BOLA) occurs when user A gets access to private data from user B. To prevent it, enforce robust user-based access controls across all your endpoints
• Broken authentication happens when a threat actor breaks through our authentication system. To prevent it, use Identity as a Service (IaaS) providers and leverage standard protocols and specifications like Open Authorisation, OpenID Connect, and JSON Web Tokens.
• Broken object property level authorisation (BOPLA) happens when a threat actor overrides (mass assignment) or gets access (excessive data exposure) to a property that should be hidden from them. To prevent it, constrain user input, use strict data models, and make sure you check thoroughly user permissions before determining what data they have access to.
• Broken function level authorisation (BFLA) occurs when users gain access to the privileges of a user group they don't belong to, for example, when a non-admin user gets access to an admin operation. To prevent it, declare user permissions or roles explicitly in their access tokens and validate their access against all operations in your API.
• Unrestricted access to sensitive business flows refers to a threat actor's ability to abuse our business model through our API. A well-known example is scalper bots that buy the whole stock of a product and resell it at a higher price. To prevent it, constrain by design how users engage with your API and counter automated bots by serving CAPTCHA challenges.

#Secure #Apis #Design #Build #Implement #Development

Credits : Manning