\nLevel Authorization<\/a>\n\tAPI 2: Broken User
\nAuthentication<\/a>\n\tAPI 3<\/a>: Excessive
\nData Exposure<\/a>\n\tAPI 4: Lack of Resources
\n& Rate Limiting<\/a>\n\tAPI 5: Broken Function
\nLevel Authorization<\/a>\n\tAPI 6: Mass
\nAssignment<\/a>\n\tAPI 7: Security
\nMisconfiguration<\/a>\n\tAPI 8:
\nInjection<\/a>\n\tAPI 9: Improper
\nAssets Management<\/a>\n\tAPI 10: Insufficient
\nLogging & Monitoring<\/a>\n\t
API 01:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tBroken Object Level Authorization\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Leverage Enterprise Data Dictionary to highlight potential exposure<\/li>\n
- Detect simplistic identifiers<\/li>\n<\/ul>\n\t
TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Generate automated BOLA scenarios<\/li>\n
- Test API resilience against BOLA\/IDOR hacking techniques<\/li>\n<\/ul>\n\t
RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Integration with fine-grained authorization systems like OPA<\/li>\n
- ID virtualization policies<\/li>\n<\/ul>\n\t
OWASP Definition<\/h4>\n
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.<\/p>\n\t
BOLA is also known as IDOR and is triggered by guessable IDs and lack of authorization checks at resources level. We can integrate via our protections with external authorization systems, acting as an enforcement point.<\/p>\n
Additionally, we have added two approaches to address the guessable IDs problem, through dedicated protection extensions:<\/p>\n
(1) Replace internal IDs by UUIDs on the fly: when IDs are returned by the back end, they are replaced by a UUID. This allows users to introduce non-guessable IDs with no need to change the APIs implementation.<\/p>\n
(2) Track IDs by session: only IDs that have been returned by the API within a session can be used in subsequent calls.<\/p>\n\t
API 02:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tBroken User Authorization\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag weak\/missing authentication schemes as well as weak transport settings<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Injection of incorrect API keys and tokens<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- JWT Validation according to RFC 8725<\/li>\n
- Access tokens\/API keys validation from API Contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Authentication is first enforced at design time: APIs with weak authentication schemes according to their risk level will be caught by the audit rules. Such APIs can be prevented from deployment in your CI\/CD pipeline<\/a>.<\/p>\nOAuth2 authorization servers endpoints (auth and token endpoints) can be protected to only allow specific grant types, enforce scopes values and access token validity time, making sure that consumers cannot use client credentials for example or enforce that a state is used with the authorization code grant, preventing attacks like\u00a0this API security breach<\/a>.<\/p>\nAdditionally, our runtime protection policies validate JWT according to the RFC 8725, published in Feb 2020, preventing attacks listed in that RFC.<\/p>\n
We are also working on supporting the FAPI security profiles\u00a0https:\/\/openid.net\/wg\/fapi\/<\/a>\u00a0with pre-built protections.<\/p>\n\tAPI 03:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tExcessive Data Exposure\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag non-compliant response schemas<\/li>\n
- Flag missing error codes and\/or schemas<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test schemas compliance<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Blocks responses which do not match the schemas<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Helping developers to define response schema and follow them makes accidental data exposure impossible. 42Crunch enforces control at development and build time to ensure strong schemas are defined for all APIs. More than 300 controls are done as part of the API audit. Missing response codes are also flagged (401, 403, 404, 415, 500).<\/p>\n
At QA \/ testing time, the API conformance scan<\/a> will detect if responses given by the API do not match the OpenAPI contract.<\/p>\nThe 42Crunch API firewall<\/a> will block responses that do not match the schemas. When a response is invalid, the existing payload is replaced with a generic error, preventing exception leakage and\/or verbose error leakage. Responses with unknown error codes are also blocked.<\/p>\nThose services are highly complementary: if the schemas are loose, validation works all the time. So runtime support of OAS\/schemas validation is not enough, you must ensure the schemas are well-defined first.<\/p>\n\t
API 04:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tLack of Resources & Rate Limiting\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag data missing constraints (min\/max size)<\/li>\n
- Flag operations that do not declare 429 responses<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test data constraints<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Rate Limiting by API and by operation<\/li>\n
- Blocks overflow type attacks<\/li>\n
- JSON Parser protection<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
42Crunch API audit<\/a> validation rules flag loose definitions and will guide the developers to add constraints to string sizes, integer sizes and array sizes, limiting exposure to various overflow attacks. The audit also raises an issue when an API does not define 429 error codes for rate limiting.<\/p>\nAt conformance scan<\/a> time, constraints are validated by sending data outside of limits and analyzing the API response.<\/p>\nFinally, at runtime, the expected limits are enforced. Rate-limiting protections can be added to the OAS file (at the API or operation level) as well as JSON parser protections (payload size, complexity).<\/p>\n\t
API 05:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tBroken Function Level Authorization\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Automated audit to discover APIs<\/li>\n
- Flag missing\/invalid OAuth scopes<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test how API handles unknown requests (verbs, paths, data)<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Block requests with unexpected verbs and paths\/subpaths (including path traversal attacks)<\/li>\n
- Blocks unknown APIs requests<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
At runtime, 42Crunch ensures that only verbs and paths defined in the OAS-based contract can be called. APIs which are not defined are blocked as well, preventing unknown APIs from being called.<\/p>\n
Additionally, at design time, customers can use our audit discovery mechanisms via CI\/CD<\/a> to uncover shadow APIs and automatically audit and report<\/a> them.<\/p>\n\tAPI 06:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tMass Assignment\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag non-compliant request schemas<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test schemas compliance<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Blocks requests which do not match schemas<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, 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.<\/p>\n\t
Similarly to API3, API Linter<\/a> also analyzes requests schemas\/forms flagging missing constraints and patterns, as well as headers, path and query parameters.<\/p>\nAt runtime, the 42Crunch enforces the data constraints and blocks invalid requests, preventing hackers from injecting any undefined data or calling unknown path and verbs.<\/p>\n\t
API 07:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tSecurity Misconfiguration\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Audit is used to discover potential issues early in lifecycle and is automated for security governance<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Tests automatically for API implementation security issues at early development stages<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Secure TLS configuration<\/li>\n
- Blocks by default<\/li>\n
- Safe error messages<\/li>\n
- Automatic injection of security headers<\/li>\n
- Automatic enforcement of API contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Our security as code approach allows enterprises to make security fully part of the API lifecycle, starting at design time. 42Crunch API Security Audit<\/a> flags unsecure transport configuration and automatically validates standard headers (such as Content-Type) within the OAS definition.<\/p>\nThe 42Crunch runtime only accepts secure connections, supports MTLS inbound\/outbound and only accepts TLS1.2 with strong cipher suites. Standard protections include CORS support and automatic injection of security headers. Our API firewall<\/a> is constantly kept up to date for latest CVEs and checked for security vulnerabilities.<\/p>\nThe API firewall runtime is very small and can be deployed for all APIs, with very limited impact to performance. Since the configuration only depends on the OAS file, firewalls can be put in place early in all environments, including development, limiting the possibility to inject security issues in early lifecycle phases.<\/p>\n
Error messages which do not match the expected formats are blocked and replaced with standard ones which do not give away internal information.<\/p>\n\t
API 08:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tInjection\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flags loose schemas and data definitions (headers, query and path params)<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Tests resistance to bad data formats and invalid data types<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Protect from injections through validation of all data against API contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Injections hit APIs via unsanitized inputs. By forcing the companies to define tightened input schemas and patterns, 42Crunch eliminates the risk of arbitrary payloads hitting the backend.<\/p>\n
Additionally to the standard OAS based allowlist, customers can deploy denylist-based protections for properties where a precise regex is not an option.<\/p>\n\t
API 09:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tImproper Assets Management\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Integration of audit with CI\/CD pipeline for automatic discovery of APIs<\/li>\n
- Single pane of glass view of all APIs security status across the enterprise<\/li>\n<\/ul>\n\t
TEST & QA
\n<\/center>(API Scan)<\/center>\n\t\n- Tests for unknown verbs<\/li>\n
- Detects unknown responses<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Unknown traffic is blocked by default<\/li>\n
- Non-blocking mode can be enabled for discovery\/monitoring<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
42Crunch CI\/CD integration<\/a> is core to addressing this issue: by providing a security point of control whenever code is pushed to the platform and by delivering a discovery mechanism that leaves no room for unknown APIs in any code repository. All discovered APIs can be viewed in our dashboard, or in your dashboard of choice, providing instant visibility to security and dev teams alike. This is even more critical in companies where APIs are implemented across various technologies and where global visibility\/governance across those technologies is challenging.<\/p>\nAt runtime, unknown paths and APIs traffic will be blocked by default. The firewall<\/a> listening only mode will allow you to record invalid traffic, without blocking it, and discover unwanted\/forgotten traffic.<\/p>\n\tAPI 10:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tInsufficient Logging & Monitoring\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\tN\/A<\/p>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\tN\/A<\/p>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- All traffic is monitored and logged<\/li>\n
- Integration with enterprises logging infrastructure<\/li>\n
- Integration with SIEM<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
All transactions flowing through the API Protect<\/a> (successful or blocked) are recorded and can be leveraged via our API Security platform<\/a> or via the customers logging\/monitoring platform of choice. Attack information can be pushed to SIEM<\/a> using Common Event Format or JSON for correlation and incident response. Incidents are also visible in our platform’s real-time security dashboard.<\/p>\n\t3-Part Webinar series<\/h4>\n\n\t\t\n\t\tOWASP API Security Top 10\u00a0\n\t\t<\/a>\n\t<\/h2>\n\n\t\tFind, Fix and Secure your APIs\n\t<\/h2>\n\t\t\t\t![\"Speaker](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/bb-plugin\/cache\/Speaker-Philippe-Deryck-circle.jpeg\" "\\"Speaker")
\n\t
Dr. Philippe De Ryck<\/p>\n\t
Dr. Philippe De Ryck, Web Security Expert with Pragmatic Web Security and Colin Domoney of 42Crunch and APISecurity.io, take a deep dive into understanding and addressing the OWASP API Security Top 10 issues.<\/p>\n
\n\t\tReady to Learn More?\n\t<\/h2>\n\t
\n\t\tBroken Object Level Authorization\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Leverage Enterprise Data Dictionary to highlight potential exposure<\/li>\n
- Detect simplistic identifiers<\/li>\n<\/ul>\n\t
TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Generate automated BOLA scenarios<\/li>\n
- Test API resilience against BOLA\/IDOR hacking techniques<\/li>\n<\/ul>\n\t
RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Integration with fine-grained authorization systems like OPA<\/li>\n
- ID virtualization policies<\/li>\n<\/ul>\n\t
OWASP Definition<\/h4>\n
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.<\/p>\n\t
BOLA is also known as IDOR and is triggered by guessable IDs and lack of authorization checks at resources level. We can integrate via our protections with external authorization systems, acting as an enforcement point.<\/p>\n
Additionally, we have added two approaches to address the guessable IDs problem, through dedicated protection extensions:<\/p>\n
(1) Replace internal IDs by UUIDs on the fly: when IDs are returned by the back end, they are replaced by a UUID. This allows users to introduce non-guessable IDs with no need to change the APIs implementation.<\/p>\n
(2) Track IDs by session: only IDs that have been returned by the API within a session can be used in subsequent calls.<\/p>\n\t
API 02:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tBroken User Authorization\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag weak\/missing authentication schemes as well as weak transport settings<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Injection of incorrect API keys and tokens<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- JWT Validation according to RFC 8725<\/li>\n
- Access tokens\/API keys validation from API Contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Authentication is first enforced at design time: APIs with weak authentication schemes according to their risk level will be caught by the audit rules. Such APIs can be prevented from deployment in your CI\/CD pipeline<\/a>.<\/p>\nOAuth2 authorization servers endpoints (auth and token endpoints) can be protected to only allow specific grant types, enforce scopes values and access token validity time, making sure that consumers cannot use client credentials for example or enforce that a state is used with the authorization code grant, preventing attacks like\u00a0this API security breach<\/a>.<\/p>\nAdditionally, our runtime protection policies validate JWT according to the RFC 8725, published in Feb 2020, preventing attacks listed in that RFC.<\/p>\n
We are also working on supporting the FAPI security profiles\u00a0https:\/\/openid.net\/wg\/fapi\/<\/a>\u00a0with pre-built protections.<\/p>\n\tAPI 03:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tExcessive Data Exposure\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag non-compliant response schemas<\/li>\n
- Flag missing error codes and\/or schemas<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test schemas compliance<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Blocks responses which do not match the schemas<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Helping developers to define response schema and follow them makes accidental data exposure impossible. 42Crunch enforces control at development and build time to ensure strong schemas are defined for all APIs. More than 300 controls are done as part of the API audit. Missing response codes are also flagged (401, 403, 404, 415, 500).<\/p>\n
At QA \/ testing time, the API conformance scan<\/a> will detect if responses given by the API do not match the OpenAPI contract.<\/p>\nThe 42Crunch API firewall<\/a> will block responses that do not match the schemas. When a response is invalid, the existing payload is replaced with a generic error, preventing exception leakage and\/or verbose error leakage. Responses with unknown error codes are also blocked.<\/p>\nThose services are highly complementary: if the schemas are loose, validation works all the time. So runtime support of OAS\/schemas validation is not enough, you must ensure the schemas are well-defined first.<\/p>\n\t
API 04:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tLack of Resources & Rate Limiting\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag data missing constraints (min\/max size)<\/li>\n
- Flag operations that do not declare 429 responses<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test data constraints<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Rate Limiting by API and by operation<\/li>\n
- Blocks overflow type attacks<\/li>\n
- JSON Parser protection<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
42Crunch API audit<\/a> validation rules flag loose definitions and will guide the developers to add constraints to string sizes, integer sizes and array sizes, limiting exposure to various overflow attacks. The audit also raises an issue when an API does not define 429 error codes for rate limiting.<\/p>\nAt conformance scan<\/a> time, constraints are validated by sending data outside of limits and analyzing the API response.<\/p>\nFinally, at runtime, the expected limits are enforced. Rate-limiting protections can be added to the OAS file (at the API or operation level) as well as JSON parser protections (payload size, complexity).<\/p>\n\t
API 05:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tBroken Function Level Authorization\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Automated audit to discover APIs<\/li>\n
- Flag missing\/invalid OAuth scopes<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test how API handles unknown requests (verbs, paths, data)<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Block requests with unexpected verbs and paths\/subpaths (including path traversal attacks)<\/li>\n
- Blocks unknown APIs requests<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
At runtime, 42Crunch ensures that only verbs and paths defined in the OAS-based contract can be called. APIs which are not defined are blocked as well, preventing unknown APIs from being called.<\/p>\n
Additionally, at design time, customers can use our audit discovery mechanisms via CI\/CD<\/a> to uncover shadow APIs and automatically audit and report<\/a> them.<\/p>\n\tAPI 06:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tMass Assignment\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flag non-compliant request schemas<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Test schemas compliance<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Blocks requests which do not match schemas<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, 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.<\/p>\n\t
Similarly to API3, API Linter<\/a> also analyzes requests schemas\/forms flagging missing constraints and patterns, as well as headers, path and query parameters.<\/p>\nAt runtime, the 42Crunch enforces the data constraints and blocks invalid requests, preventing hackers from injecting any undefined data or calling unknown path and verbs.<\/p>\n\t
API 07:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tSecurity Misconfiguration\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Audit is used to discover potential issues early in lifecycle and is automated for security governance<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Tests automatically for API implementation security issues at early development stages<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Secure TLS configuration<\/li>\n
- Blocks by default<\/li>\n
- Safe error messages<\/li>\n
- Automatic injection of security headers<\/li>\n
- Automatic enforcement of API contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Our security as code approach allows enterprises to make security fully part of the API lifecycle, starting at design time. 42Crunch API Security Audit<\/a> flags unsecure transport configuration and automatically validates standard headers (such as Content-Type) within the OAS definition.<\/p>\nThe 42Crunch runtime only accepts secure connections, supports MTLS inbound\/outbound and only accepts TLS1.2 with strong cipher suites. Standard protections include CORS support and automatic injection of security headers. Our API firewall<\/a> is constantly kept up to date for latest CVEs and checked for security vulnerabilities.<\/p>\nThe API firewall runtime is very small and can be deployed for all APIs, with very limited impact to performance. Since the configuration only depends on the OAS file, firewalls can be put in place early in all environments, including development, limiting the possibility to inject security issues in early lifecycle phases.<\/p>\n
Error messages which do not match the expected formats are blocked and replaced with standard ones which do not give away internal information.<\/p>\n\t
API 08:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tInjection\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Flags loose schemas and data definitions (headers, query and path params)<\/li>\n<\/ul>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\t\n- Tests resistance to bad data formats and invalid data types<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Protect from injections through validation of all data against API contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Injections hit APIs via unsanitized inputs. By forcing the companies to define tightened input schemas and patterns, 42Crunch eliminates the risk of arbitrary payloads hitting the backend.<\/p>\n
Additionally to the standard OAS based allowlist, customers can deploy denylist-based protections for properties where a precise regex is not an option.<\/p>\n\t
API 09:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tImproper Assets Management\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\t\n- Integration of audit with CI\/CD pipeline for automatic discovery of APIs<\/li>\n
- Single pane of glass view of all APIs security status across the enterprise<\/li>\n<\/ul>\n\t
TEST & QA
\n<\/center>(API Scan)<\/center>\n\t\n- Tests for unknown verbs<\/li>\n
- Detects unknown responses<\/li>\n<\/ul>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- Unknown traffic is blocked by default<\/li>\n
- Non-blocking mode can be enabled for discovery\/monitoring<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
42Crunch CI\/CD integration<\/a> is core to addressing this issue: by providing a security point of control whenever code is pushed to the platform and by delivering a discovery mechanism that leaves no room for unknown APIs in any code repository. All discovered APIs can be viewed in our dashboard, or in your dashboard of choice, providing instant visibility to security and dev teams alike. This is even more critical in companies where APIs are implemented across various technologies and where global visibility\/governance across those technologies is challenging.<\/p>\nAt runtime, unknown paths and APIs traffic will be blocked by default. The firewall<\/a> listening only mode will allow you to record invalid traffic, without blocking it, and discover unwanted\/forgotten traffic.<\/p>\n\tAPI 10:<\/h4>\n\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n\n\t\tInsufficient Logging & Monitoring\n\t<\/h2>\n\tDESIGN & CODE
\n(API Audit)<\/center>\n\tN\/A<\/p>\n\t
<\/center>TEST & QA<\/center>(API Scan)<\/center><\/p>\n\tN\/A<\/p>\n\t
<\/center>RUNTIME PROTECTION<\/center>(API Protect)<\/center><\/p>\n\t\n- All traffic is monitored and logged<\/li>\n
- Integration with enterprises logging infrastructure<\/li>\n
- Integration with SIEM<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
All transactions flowing through the API Protect<\/a> (successful or blocked) are recorded and can be leveraged via our API Security platform<\/a> or via the customers logging\/monitoring platform of choice. Attack information can be pushed to SIEM<\/a> using Common Event Format or JSON for correlation and incident response. Incidents are also visible in our platform’s real-time security dashboard.<\/p>\n\t3-Part Webinar series<\/h4>\n\n\t\t\n\t\tOWASP API Security Top 10\u00a0\n\t\t<\/a>\n\t<\/h2>\n\n\t\tFind, Fix and Secure your APIs\n\t<\/h2>\n\t\t\t\t\n\t
Dr. Philippe De Ryck<\/p>\n\t
Dr. Philippe De Ryck, Web Security Expert with Pragmatic Web Security and Colin Domoney of 42Crunch and APISecurity.io, take a deep dive into understanding and addressing the OWASP API Security Top 10 issues.<\/p>\n
\n\t\tReady to Learn More?\n\t<\/h2>\n\t
\n(API Audit)<\/center>\n\t
- \n
- Leverage Enterprise Data Dictionary to highlight potential exposure<\/li>\n
- Detect simplistic identifiers<\/li>\n<\/ul>\n\t
TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Generate automated BOLA scenarios<\/li>\n
- Test API resilience against BOLA\/IDOR hacking techniques<\/li>\n<\/ul>\n\t
RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Integration with fine-grained authorization systems like OPA<\/li>\n
- ID virtualization policies<\/li>\n<\/ul>\n\t
OWASP Definition<\/h4>\n
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.<\/p>\n\t
BOLA is also known as IDOR and is triggered by guessable IDs and lack of authorization checks at resources level. We can integrate via our protections with external authorization systems, acting as an enforcement point.<\/p>\n
Additionally, we have added two approaches to address the guessable IDs problem, through dedicated protection extensions:<\/p>\n
(1) Replace internal IDs by UUIDs on the fly: when IDs are returned by the back end, they are replaced by a UUID. This allows users to introduce non-guessable IDs with no need to change the APIs implementation.<\/p>\n
(2) Track IDs by session: only IDs that have been returned by the API within a session can be used in subsequent calls.<\/p>\n\t
API 02:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tBroken User Authorization\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Flag weak\/missing authentication schemes as well as weak transport settings<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Injection of incorrect API keys and tokens<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- JWT Validation according to RFC 8725<\/li>\n
- Access tokens\/API keys validation from API Contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Authentication is first enforced at design time: APIs with weak authentication schemes according to their risk level will be caught by the audit rules. Such APIs can be prevented from deployment in your CI\/CD pipeline<\/a>.<\/p>\n
OAuth2 authorization servers endpoints (auth and token endpoints) can be protected to only allow specific grant types, enforce scopes values and access token validity time, making sure that consumers cannot use client credentials for example or enforce that a state is used with the authorization code grant, preventing attacks like\u00a0this API security breach<\/a>.<\/p>\n
Additionally, our runtime protection policies validate JWT according to the RFC 8725, published in Feb 2020, preventing attacks listed in that RFC.<\/p>\n
We are also working on supporting the FAPI security profiles\u00a0https:\/\/openid.net\/wg\/fapi\/<\/a>\u00a0with pre-built protections.<\/p>\n\t
API 03:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tExcessive Data Exposure\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Flag non-compliant response schemas<\/li>\n
- Flag missing error codes and\/or schemas<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Test schemas compliance<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Blocks responses which do not match the schemas<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Helping developers to define response schema and follow them makes accidental data exposure impossible. 42Crunch enforces control at development and build time to ensure strong schemas are defined for all APIs. More than 300 controls are done as part of the API audit. Missing response codes are also flagged (401, 403, 404, 415, 500).<\/p>\n
At QA \/ testing time, the API conformance scan<\/a> will detect if responses given by the API do not match the OpenAPI contract.<\/p>\n
The 42Crunch API firewall<\/a> will block responses that do not match the schemas. When a response is invalid, the existing payload is replaced with a generic error, preventing exception leakage and\/or verbose error leakage. Responses with unknown error codes are also blocked.<\/p>\n
Those services are highly complementary: if the schemas are loose, validation works all the time. So runtime support of OAS\/schemas validation is not enough, you must ensure the schemas are well-defined first.<\/p>\n\t
API 04:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tLack of Resources & Rate Limiting\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Flag data missing constraints (min\/max size)<\/li>\n
- Flag operations that do not declare 429 responses<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Test data constraints<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Rate Limiting by API and by operation<\/li>\n
- Blocks overflow type attacks<\/li>\n
- JSON Parser protection<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
42Crunch API audit<\/a> validation rules flag loose definitions and will guide the developers to add constraints to string sizes, integer sizes and array sizes, limiting exposure to various overflow attacks. The audit also raises an issue when an API does not define 429 error codes for rate limiting.<\/p>\n
At conformance scan<\/a> time, constraints are validated by sending data outside of limits and analyzing the API response.<\/p>\n
Finally, at runtime, the expected limits are enforced. Rate-limiting protections can be added to the OAS file (at the API or operation level) as well as JSON parser protections (payload size, complexity).<\/p>\n\t
API 05:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tBroken Function Level Authorization\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Automated audit to discover APIs<\/li>\n
- Flag missing\/invalid OAuth scopes<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Test how API handles unknown requests (verbs, paths, data)<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Block requests with unexpected verbs and paths\/subpaths (including path traversal attacks)<\/li>\n
- Blocks unknown APIs requests<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
At runtime, 42Crunch ensures that only verbs and paths defined in the OAS-based contract can be called. APIs which are not defined are blocked as well, preventing unknown APIs from being called.<\/p>\n
Additionally, at design time, customers can use our audit discovery mechanisms via CI\/CD<\/a> to uncover shadow APIs and automatically audit and report<\/a> them.<\/p>\n\t
API 06:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tMass Assignment\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Flag non-compliant request schemas<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Test schemas compliance<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Blocks requests which do not match schemas<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, 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.<\/p>\n\t
Similarly to API3, API Linter<\/a> also analyzes requests schemas\/forms flagging missing constraints and patterns, as well as headers, path and query parameters.<\/p>\n
At runtime, the 42Crunch enforces the data constraints and blocks invalid requests, preventing hackers from injecting any undefined data or calling unknown path and verbs.<\/p>\n\t
API 07:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tSecurity Misconfiguration\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Audit is used to discover potential issues early in lifecycle and is automated for security governance<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Tests automatically for API implementation security issues at early development stages<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Secure TLS configuration<\/li>\n
- Blocks by default<\/li>\n
- Safe error messages<\/li>\n
- Automatic injection of security headers<\/li>\n
- Automatic enforcement of API contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Our security as code approach allows enterprises to make security fully part of the API lifecycle, starting at design time. 42Crunch API Security Audit<\/a> flags unsecure transport configuration and automatically validates standard headers (such as Content-Type) within the OAS definition.<\/p>\n
The 42Crunch runtime only accepts secure connections, supports MTLS inbound\/outbound and only accepts TLS1.2 with strong cipher suites. Standard protections include CORS support and automatic injection of security headers. Our API firewall<\/a> is constantly kept up to date for latest CVEs and checked for security vulnerabilities.<\/p>\n
The API firewall runtime is very small and can be deployed for all APIs, with very limited impact to performance. Since the configuration only depends on the OAS file, firewalls can be put in place early in all environments, including development, limiting the possibility to inject security issues in early lifecycle phases.<\/p>\n
Error messages which do not match the expected formats are blocked and replaced with standard ones which do not give away internal information.<\/p>\n\t
API 08:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tInjection\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Flags loose schemas and data definitions (headers, query and path params)<\/li>\n<\/ul>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t - \n
- Tests resistance to bad data formats and invalid data types<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Protect from injections through validation of all data against API contract<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
Injections hit APIs via unsanitized inputs. By forcing the companies to define tightened input schemas and patterns, 42Crunch eliminates the risk of arbitrary payloads hitting the backend.<\/p>\n
Additionally to the standard OAS based allowlist, customers can deploy denylist-based protections for properties where a precise regex is not an option.<\/p>\n\t
API 09:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tImproper Assets Management\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\t- \n
- Integration of audit with CI\/CD pipeline for automatic discovery of APIs<\/li>\n
- Single pane of glass view of all APIs security status across the enterprise<\/li>\n<\/ul>\n\t
TEST & QA
\n<\/center>(API Scan)<\/center>\n\t - \n
- Tests for unknown verbs<\/li>\n
- Detects unknown responses<\/li>\n<\/ul>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- Unknown traffic is blocked by default<\/li>\n
- Non-blocking mode can be enabled for discovery\/monitoring<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
42Crunch CI\/CD integration<\/a> is core to addressing this issue: by providing a security point of control whenever code is pushed to the platform and by delivering a discovery mechanism that leaves no room for unknown APIs in any code repository. All discovered APIs can be viewed in our dashboard, or in your dashboard of choice, providing instant visibility to security and dev teams alike. This is even more critical in companies where APIs are implemented across various technologies and where global visibility\/governance across those technologies is challenging.<\/p>\n
At runtime, unknown paths and APIs traffic will be blocked by default. The firewall<\/a> listening only mode will allow you to record invalid traffic, without blocking it, and discover unwanted\/forgotten traffic.<\/p>\n\t
API 10:<\/h4>\n
\n\t\t42Crunch\u00a0Approach\n\t<\/h2>\n
\n\t\tInsufficient Logging & Monitoring\n\t<\/h2>\n\t
DESIGN & CODE
\n(API Audit)<\/center>\n\tN\/A<\/p>\n\t
<\/center> TEST & QA<\/center> (API Scan)<\/center><\/p>\n\t N\/A<\/p>\n\t
<\/center> RUNTIME PROTECTION<\/center> (API Protect)<\/center><\/p>\n\t - \n
- All traffic is monitored and logged<\/li>\n
- Integration with enterprises logging infrastructure<\/li>\n
- Integration with SIEM<\/li>\n<\/ul>\n
OWASP Definition<\/h4>\n
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.<\/p>\n\t
All transactions flowing through the API Protect<\/a> (successful or blocked) are recorded and can be leveraged via our API Security platform<\/a> or via the customers logging\/monitoring platform of choice. Attack information can be pushed to SIEM<\/a> using Common Event Format or JSON for correlation and incident response. Incidents are also visible in our platform’s real-time security dashboard.<\/p>\n\t
3-Part Webinar series<\/h4>\n
\n\t\t\n\t\tOWASP API Security Top 10\u00a0\n\t\t<\/a>\n\t<\/h2>\n
\n\t\tFind, Fix and Secure your APIs\n\t<\/h2>\n\t\t\t\t
\n\tDr. Philippe De Ryck<\/p>\n\t
Dr. Philippe De Ryck, Web Security Expert with Pragmatic Web Security and Colin Domoney of 42Crunch and APISecurity.io, take a deep dive into understanding and addressing the OWASP API Security Top 10 issues.<\/p>\n
\n\t\tReady to Learn More?\n\t<\/h2>\n\t
- Protect from injections through validation of all data against API contract<\/li>\n<\/ul>\n
- Tests resistance to bad data formats and invalid data types<\/li>\n<\/ul>\n\t
- Flags loose schemas and data definitions (headers, query and path params)<\/li>\n<\/ul>\n\t
- Tests automatically for API implementation security issues at early development stages<\/li>\n<\/ul>\n\t
- Audit is used to discover potential issues early in lifecycle and is automated for security governance<\/li>\n<\/ul>\n\t
- Blocks requests which do not match schemas<\/li>\n<\/ul>\n
- Test schemas compliance<\/li>\n<\/ul>\n\t
- Flag non-compliant request schemas<\/li>\n<\/ul>\n\t
- Test how API handles unknown requests (verbs, paths, data)<\/li>\n<\/ul>\n\t
- Test data constraints<\/li>\n<\/ul>\n\t
- Blocks responses which do not match the schemas<\/li>\n<\/ul>\n
- Test schemas compliance<\/li>\n<\/ul>\n\t
- Injection of incorrect API keys and tokens<\/li>\n<\/ul>\n\t
- Flag weak\/missing authentication schemes as well as weak transport settings<\/li>\n<\/ul>\n\t