API Protection and Access Control features in the WSO2 API Manager

For those of you interested in learning about API Security and want to know what the WSO2 API Management platform has to offer out of the box, here’s a quick list with the relevant documentation links of the product to follow through.

API Access Control

Authentication

Authenticating to APIs is about proving your identity to the API. OAuth2.0 is the de-facto standard of authenticating to REST APIs. It uses authorization tokens called access tokens to represent a user’s identity when a consumer application communicates with an API. It does this without having the need for the user to share his/her password with the API.

In addition to OAuth2.0 there are other common authentication mechanisms used in APIs. You can find the list below.

• OAuth2.0: https://apim.docs.wso2.com/en/latest/learn/api-security/api-authentication/secure-apis-using-oauth2-tokens/
• OAuth2.0 Grant Types: https://apim.docs.wso2.com/en/latest/learn/api-security/oauth2/grant-types/overview/
• OIDC: https://apim.docs.wso2.com/en/latest/learn/api-security/openid-connect/obtaining-user-profile-information-with-openid-connect/
• API Key: https://apim.docs.wso2.com/en/latest/learn/api-security/api-authentication/secure-apis-using-api-keys/
• Basic Authentication: https://apim.docs.wso2.com/en/latest/learn/api-security/api-authentication/secure-apis-using-basic-authentication/
• Mutual TLS: https://apim.docs.wso2.com/en/latest/learn/api-security/api-authentication/secure-apis-using-mutual-ssl/

Authorization

Authorization is about privileges. Authorization rules define what actions a user/application is allowed to perform on an API. It is also used in certain cases to determine what data you can/cannot see from the API’s responses.

• Role Based Access Control through OAuth2.0 Scopes: https://apim.docs.wso2.com/en/latest/learn/api-security/oauth2/oauth2-scopes/fine-grained-access-control-with-oauth-scopes/
• XACML Based Access Control for fine grained authorization: https://apim.docs.wso2.com/en/latest/learn/api-security/authorization/role-based-access-control-using-xacml/

Rate Limiting

Rate limiting policies control the rate/frequency at which an API can be consumed. In certain cases it is used to control the amount of data (bytes) that can be transferred in a given time window. They are useful for preventing an API from being used beyond its capacity, to prevent DDOS attacks, to monetize APIs through subscription plans, to provide fair usage limits to its consumers and so on.

• https://apim.docs.wso2.com/en/latest/learn/rate-limiting/introducing-throttling-use-cases/

Rate limiting GraphQL APIs cannot be done alone by limiting the frequency at which an API is called. Consumers of GraphQL APIs can use queries with higher complexity to retrieve more data, instead of calling the API many times. It is therefore important to rate limit GraphQL APIs by having a cap on the complexity of queries.

• https://apim.docs.wso2.com/en/next/learn/rate-limiting/graphql-api/overview-query-limits-for-graphql/

API Protection

CORS Protection

When an API is being accessed by Javascript (web browsers) of web applications running on a different host than the API itself, web browsers enforce the same origin policy which prevents the API from being used unless access to the API is granted through Cross Origin Resource Sharing (CORS).

• https://apim.docs.wso2.com/en/latest/reference/config-catalog/#api-m-cors-configurations

Bot Detection

Malicious bots scan API hosts to find vulnerable paths that can be attacked. These bots have to be detected and prevented as fast as possible to prevent them harming APIs in any way.

• https://apim.docs.wso2.com/en/latest/learn/api-security/threat-protection/bot-detection/

Protection against Malicious Payloads

Malicious payloads are used by attackers to harm APIs by either DOS attacks, to steal data, to modify or delete data and so on. Protection against malicious payloads can be enforced by checking for malicious content in the payloads and by making sure API request and responses conform to a predefined schema.

• Protection against JSON message threats: https://apim.docs.wso2.com/en/latest/learn/api-gateway/threat-protectors/json-threat-protection-for-api-gateway/
• Protection against XML message threats: https://apim.docs.wso2.com/en/latest/learn/api-gateway/threat-protectors/xml-threat-protection-for-api-gateway/
• JSON schema enforcement: https://apim.docs.wso2.com/en/latest/learn/api-security/api-request-response-schema-validation/json-schema-validator/
• Validations using regular expressions for SQL injection prevention, Javascript attack prevention and so on: https://apim.docs.wso2.com/en/latest/learn/api-gateway/threat-protectors/regular-expression-threat-protection-for-api-gateway/

Data Masking and Data Redaction

It is sometimes necessary to remove certain fields from API data to prevent them being visible to certain users. Think of a scenario where you have to pull profile information of a user when all you need is his/her username. You need to prevent sensitive information such as the user’s phone number, address, etc being visible to users who are not privileged to see them. It is therefore necessary to apply data masking and redaction rules on API data. Sometimes this needs to be done based on privileges. You can achieve this through message mediation/transformation policies applied at the API Gateway.

• https://apim.docs.wso2.com/en/latest/learn/api-gateway/message-mediation/changing-the-default-mediation-flow-of-api-requests/

Fraud Detection

A request bearing a valid access credential and privileges may not always mean it is genuine. What if the access token is a stolen one? Detecting these type of abusive attacks require monitoring the API system for access patterns and knowing how to detect suspicious and abnormal API calls.

• Detecting token theft and other abnormal access patterns: https://apim.docs.wso2.com/en/latest/learn/analytics/managing-alerts-with-real-time-analytics/alert-types/
• AI based advanced fraud detection: https://wso2.com/api-management/ai-driven-security-enforcement-for-api-management/

Propagating security context to downstream APIs

An API Gateway is a reverse proxy to API. It intercepts requests from consumer applications and applies API Management logic on them. An API Gateway usually terminates consumer authentication and authorization when processing requests. When request messages reach downstream business APIs, they need to check for the authenticity of these messages and they need to know the user context (claims) of the actual consumer of these APIs. To facilitate this, the API gateway needs to propagate this context in a verifiable and standard manner, using JWTs.

• https://apim.docs.wso2.com/en/latest/learn/api-gateway/passing-end-user-attributes-to-the-backend/passing-enduser-attributes-to-the-backend-using-jwt/

OWASP Top 10 API Threats

To learn about how you can use the WSO2 API Gateway to make your APIs safe against the OWASP Top API Threats, see this 20 minute two part video blog.

• API1 to API5: https://www.youtube.com/watch?v=LInFNbhrTwQ&feature=emb_logo
• API6 to API10: https://www.youtube.com/watch?v=U7moIMvrWCE&feature=youtu.be

Security assessment of API definitions

The OpenAPI specs used for describing REST APIs contain important security aspects of an API. Making a security assessment on these API definitions would highly benefit API developers and API operators in ensuring the safety and reliability of published APIs. WSO2 integrates with apisecurity.io for assessing the “security score” of REST APIs. This helps API producers to produce safer APIs with higher quality.

• https://apim.docs.wso2.com/en/latest/learn/api-security/configuring-api-security-audit/

To learn more about API Security, visit https://wso2.com/api-security

Got any questions? I’d love to have a chat :). You can reach me on twitter at https://twitter.com/nuwandias