Building better security for your API platform using Azure API Management

Editor's Notes

• #4: 3
• #7: Payment data User information Large companies, so can also happen to you Largest I found is 100 million
• #9: 5
• #10: Talk about the challenge, and how API Management solves each of these. Rustig spreken! 3 minuten
• #11: 9
• #12: 11 Users use connected experiences Use a firewall like application gateway to block suspicious requests Forward valid requests to API Management Authenticate, validate and sanitize Only pass on validated and trusted requests
• #13: 12
• #16: 15
• #17: https://apifriends.com/api-security/api-security-best-practices/ 1. Be cryptic. Nothing going over the line should be in the clear, for internal or external communications. 2. Don’t talk to strangers. You should always know who is calling your APIs, at least through an API key (asymmetric key) or basic access authentication (user/password). 3. Delegate all Responsibility. You should always be delegating authorization and/or authentication of your APIs, don’t reinvent the wheel. 4. Call Security Experts Use experienced Antivirus systems or ICAP servers to help you with security. 5. Be a stalker. You need to be ready to troubleshoot in case of error: so audit and log relevant information on the server – and keep that history as long as it is reasonable. 6. Share as Little as Possible Only display as little information as possible in your answers, especially in error messages. 7. Throttle yourself. You should restrict access to your system to a limited number of messages per second, to protect your backend system bandwidth according to your servers’ capacity. 8. Be picky and refuse surprise gifts, especially if they are big. You should check everything your server accepts. Be careful to refuse any added content, data that is too big, and always validate the content. 9. Network and be up to date. A good API should lean on a secured network and up-to-date services to be solid and always benefit from the latest security fixes. Using a Cloud offering can help on this. 10. Follow OWASP top 10 This is a list of the 10 worst vulnerabilities, ranked according to their exploitability and impact, so make sure to secure yourself against all of these. 11. Build a wall.  Your API security should be organized into two layers, a DMZ with an API firewall to execute basic security mechanisms and a LAN with advanced security mechanisms on the content of data. 12. API Management Opt for a mature and performant API Management solution with all these options to save your money, time, and resources, and increase your time to market. 1. Encryption Be cryptic. Nothing should be in the clear, for internal or external communications. You and your partners should cipher all exchanges with TLS (the successor to SSL), whether it is one-way encryption (standard one-way TLS) or even better, mutual encryption (two-way TLS). Use the latest TLS versions to block the usage of the weakest cipher suites. 2. Authentication Don’t talk to strangers. You should always know who is calling your APIs, at least through an API key (asymmetric key) or basic access authentication (user/password), to increase the difficulty to hack your system.  3. OAuth & OpenID Connect Delegate all Responsibility. A good manager delegates responsibility and so does a great API. You should be delegating authorization and/or authentication of your APIs. What is OAuth? It is a magical mechanism preventing you from having to remember ten thousand passwords. Instead of creating an account on every website, you can connect through another provider’s credentials, for example, Facebook or Google. For APIs, it works the same way: the API provider relies on a third-party server to manage authorizations. The consumer doesn’t give their credentials but instead gives a token provided by the third-party server. It protects the consumer as they don’t disclose their credentials, and the API provider doesn’t need to care about protecting authorization data, as it only receives tokens. OAuth is a commonly used delegation protocol to convey authorizations. To secure your APIs even further and add authentication, you can add an identity layer on top of it: this is the Open Id Connect standard, extending OAuth 2.0 with ID tokens. 4. Call Security Experts You should use experienced Antivirus systems or ICAP (Internet Content Adaptation Protocol) servers to help you with security. 5. Monitoring: Audit, Log and Version Be a stalker. You need to be ready to troubleshoot in case of error: to audit and log relevant information on the server – and keep that history as long as it is reasonable in terms of capacity for your production servers. You should turn your logs into resources for debugging in case of any incidents. Also, monitoring dashboards are highly recommended tools to track your API consumption. Do not forget to add the version on all APIs, preferably in the path of the API, to offer several APIs of different versions working at the same time, and to be able to retire and depreciate one version over the other. 6. Share as Little as Possible Be paranoid. Display as little information as possible in your answers, especially in error messages. Lockdown email subjects and content to predefined messages that can’t be customized. Because IP addresses can give locations, keep them for yourself. Use IP Whitelist and IP Blacklist, if possible, to restrict access to your resources. Limit the number of administrators, separate access into different roles, and hide sensitive information in all your interfaces. 7. System Protection with Throttling and Quotas Throttle yourself. You should restrict access to your system to a limited number of messages per second, to protect your backend system bandwidth according to your servers’ capacity. You should also restrict access by API and by the user (or application) to be sure that no one will abuse the system or anyone API in particular. Throttling limits and quotas – when well set – are crucial to prevent attacks coming from different sources flooding your system with multiple requests (DDOS – Distributed Denial of Service Attack). 8. Data Validation Be picky and refuse surprise gifts, especially if they are big. You should check everything your server accepts. Be careful to refuse any added content, data that is too big, and always check the content that consumers are sending you. Use JSON or XML schema validation and check that your parameters are what they should be (string, integer…) to prevent any SQL injection or XML bomb. 9. Infrastructure Network and be up to date. A good API should lean on a good security network, infrastructure and up-to-date software (for servers, load balancers) to be solid and always benefit from the latest security fixes. 10. OWASP top 10 Avoid wasps. The OWASP (Open Web Application Security Project) top 10 is a list of the 10 worst vulnerabilities, ranked according to their exploitability and impact. In addition to the above points, to review your system, make sure you have secured all the OWASP vulnerabilities. 11. API Firewalling Build a wall. For some people, building a wall can solve all the immigration problems. This is the case, for APIs at least! Your API security should be organized into two layers: The first layer is in DMZ, with an API firewall to execute basic security mechanisms like checking the message size, SQL injections and any security based on the HTTP layer, blocking intruders early. Then forward the message to the second layer. The second layer is in LAN with advanced security mechanisms on the content of data. 12. API Gateway (API Management) Gateway to heaven. All the above mechanisms are long to implement and maintain. Instead of reinventing the wheel, you should opt for a mature and performant API Management solution with all these options to save your money, time and resources, and increase your time to market. An API Gateway will help you secure, control and monitor your traffic. In addition to helping you secure your APIs easily, an API Management solution will help you make sense of your API data, to take technical and business decisions: the key to success!
• #19: https://apisecurity.io/encyclopedia/content/owasp-api-security-top-10-cheat-sheet-a4.pdf Broken Object Level Authorization APIs tend to expose endpoints that handle object identifiers, which can be mis-used if we don’t set up proper authentication on each object. Broken User Authentication Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities. Excessive Data Exposure Where developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Lack of Resources & Rate Limiting Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. Broken Function Level Authorization Complex access control policies with different hierarchies of groups, and roles, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. Mass Assignment Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to. Security Misconfiguration Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information. Injection Injection flaws, such as SQL, NoSQL and Command Injection, occur when untrusted data is sent to an interpreter as part of a command or query. Improper Assets Management Proper and updated documentation is highly important. Proper hosts and deployed API versions inventory play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. Insufficient Logging & Monitoring Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems. Broken Object Level Authorization APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user. Broken User Authentication Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall. Excessive Data Exposure Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Lack of Resources & Rate Limiting Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. Broken Function Level Authorization Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. Mass Assignment Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to. Security Misconfiguration Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information. Injection Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Improper Assets Management APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. Insufficient Logging & Monitoring Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
• #20: 19
• #21: 19 Broken User Authentication Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall.
• #22: 30 Security Misconfiguration Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
• #23: 27 Excessive Data Exposure Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
• #24: 31 Excessive Data Exposure Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
• #25: 35 Insufficient Logging & Monitoring Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
• #26: 38
• #27: Broken Object Level Authorization APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user. Broken User Authentication Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall. Excessive Data Exposure Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Lack of Resources & Rate Limiting Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. Broken Function Level Authorization Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. Mass Assignment Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to. Security Misconfiguration Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information. Injection Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Improper Assets Management APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. Insufficient Logging & Monitoring Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
• #28: Rustig spreken!