SUPPORT

We’ve Got You Covered

Browse through the most common questions of potential and existing customers to get the most out of APIsec

How do you compare to Postman? SmartBEAR? BURP? OWASP Zap?

We are a fully automated API DevSecOps solution (this is enough for most people that would ask this question because that description implies what we do. We auto generate tests integrate into the CI/CD toolchain as well as the vulnerability management software to automatically take care of APIs across the SDLC). A team with Postman can only do 1/100 of what one person can do with our platform.

We already have in-house security engineers that fully validate our APIs.

Do your engineers cover all the negative test cases as well as the nested-negative test cases?

Do your engineers use an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database? 

Are these in-house security engineers conducting their tests during the development phase of new APIs?

We already have DAST and SAST solutions.

Regardless if you have DAST and SAST solutions do your engineers define all sensitive and personally identifiable information (PII) that your application stores and works with and review all API calls returning such information to see if these responses can be a security issue?

→ Excessive Data Exposure- Automatic tools usually can’t detect this type of vulnerability because it’s hard to differentiate between legitimate data returned from the API, and sensitive data that should not be returned without a deep understanding of the application.

We already audited our APIs

During your API audit did the testers review your API endpoints against function-level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy?

→ Broken Function Level Authorization- Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role).

Your AI/ML isn't really that advanced. We are very proactive about our cybersecurity and have a robust set of security controls so our APIs are fine.

Awesome, that is exactly why I am here. Every single security tool out there is basically a Negative security model, which require AI/ML solutions to analyze large swaths of data to make educated guesses on what type of activities should be denied. However, since you have such good security controls in place our positive security solution can define what the API was designed to do and only allow those calls to perform those predefined functions if they come from trusted sources. Therefore, we do not need to "guess" when we "know" that your APIs have the potential to be exploited. Aside from less accuracy, it can be difficult to understand exactly why the AI/ML identified something as a vulnerability especially when you consider that 70% of security teams report being overwhelmed by the constant false positives. So for it to notify you of something that needs to be fixed it's already too late, usually 200 days too late to be exact. Additionally, they must be constantly changed and updated to include the latest threats, but since our solution only permits what your specification allows we do not have to worry about that. The AI/ML we have is mainly for people with documentation that isn't as thorough as yours, as well as to validate that your design indeed does what it says. So it doesn't need to be overly complicated to "theoretically" offer value.

Most of our API's are GRPC

Most companies using GRPC API's internally still have REST API's that are open to the public. We can protect REST API's, which are the ones to protect anyways since these are public facing and are the most vulnerable.

Do you have an Apigee integration?

We have an approach with Apigee today that is straightforward.  We would use this for the Proof of Value process.

https://docs.apigee.com/api-platform/tutorials/tutorial-create-spec

Given the pricing model is per API / Application, what is an Application.

APIsec Standard $500 per Application or microservices App

APIsec Professional $1950 per Application or microservices App

One Application = One OAS / Swagger file

One microservices App = Multiple short OAS / Swagger files

Can you integrate with an on-premise Github repository?

We integrate with cloud GitHub, we can evaluate on an prem github to determine ease of integration.

Which versions of OpenAPI and Swagger do you support?

All versions.

Does your AI look at the Swagger file and determine data sensitivity levels? I.e., whether a given API handles sensitive data or not.

Yes, we look at sensitive data in the Swagger (today defined as PII) but this can be customized as needed to increase the scope of what is sensitive data (using Regex or patterns).

Can we create a Github repository for our custom playbooks?

Yes, APIsec stores its own playbooks in a Github repo.

Can I develop playbooks (to eliminate false positives) in a private Github repository and then promote those to the production Github and automatically have those playbooks go live?

Yes.

How do you calculate Bug Bounty Savings? This could be used to justify a purchase of APIsec.

We have a whitepaper that explains how the calculations are derived.

How do upgrades work? If I have built a bunch of custom Playbooks will those get affected in an upgrade.

Custom playbooks are not modified upon upgrade, rather is a private copy of the playbook.

Is there an API to build custom automations and integrations with API management layer?

APIsec is built on top of API and nearly all aspects of the product is exposed as an API.

There was a question about Capex vs Opex for vuln testing. I don't fully understand this - can you explain the question/answer?

A scanning service is Opex versus a Penetration test can be capitalized.

Can I customize the categories or is it hard-coded to the OWASP Top 10?

APIsec has over 99 categories out of the box and our users are able to customize / build additional ones as needed.   

We cover far more than the OWASP Top 10, built from our understand of the top 1000 API breaches that have occur.

Can the tool do a complete Black box test or authentication is a necessary requirement for the tool to execute its scans?

Value is maximum when we have multiple roles and tenants. The ABAC and RBAC value comes shining then. Hence, we recommend having authentication to demonstrate the value of the product.

Limited number of tests can be executed without authentication, it can be used more for initial data gathering before customer meeting, but not for product demonstration.

But wouldn't the authentication layer prevent access to unencrypted data?

Access control through authentication is one way to ensure data access, breaches are more about authenticated users having access to data that they should not. Take Facebooks API breach, Cambridge analytica had access to the “show as user” button, that was excessive data access. Salesforce allowed different tenants to query other tenants. This is a result of business logic checks not being completed. This is where APIsec shines.

Will APIsec consume a ton of transactions when it runs? We pay Apigee per-transaction.

Many of our customers run APIsec against their staging or nightly build environments. These tend to be development environments that usually don't have the per use pricing elements of production environments.

Will Apigee see APIsec as bot traffic and block it?

APIgee gateways if they are the first entry point to the API may have rate limiting enabled in which case you must set rate limits in the APIsec UI to ensure that APIgee does not see us as a BOT.

Do you have to manually declare what is allowed/not allowed for different roles for every API/endpoint?

APIsec builds the definition of what is allowed and now allowed for the roles that you provide. Using a simple workflow you can validate these permissions that we have learned and then ensure the API behaves according to your desire for the roles versus what is coded. Access control validation is a feature our customers really appreciate.

We consider Pen-Tests highly classified and worry about having this information hosted by a 3rd party.

Penetration test results are very sensitive and are accessible only to the tenant of APIsec that has appropriate permissions. APIsec is SOC2 compliant and takes steps to ensure that data within our platform is protected.

My API has only one endpoint. Is this ok for a POV?

With only one endpoint you likely will only be able to apply Injection type of attack playbooks. Much better to identify a more complex API to allow APIsec to run broader range of attack scenarios.

How do we handle Shadow API's?

Discovery of Shadow APIs is a serious problem. The way to uncover these is to look at communications traffic and uncover API traffic that is not assigned to a known API. This requires an inline deployment. We have purposefully focused on the problem of logic vulnerabilities that expose data that should not be exposed. The breaches today are occurring from lack of good protections where authenticated users are able to access and modify data that is not theirs resulting in large and significantly impacting breaches.

Today we don’t solve the discovery of shadow or rogue APIs rather we focus on the securing of APIs that are known and critical to your business.

What kind of API is suitable for POV?

1) We are looking for an API with different methods, read, write, modify.

2) We are looking for an API with different tenants / users to test ABAC

3) We are looking for an API with different roles to test RBAC

What are the deployment options/ requirements for APIsec Scanners?

1) For public APIs: use APIsec public cloud scanner.

2) For private on premise APIs: use the APIsec kuberetes or docker container (we will provide the instructions to instantiate)

3) For API on the customer cloud (GCP, Azure, AWS): we can use your credentials to setup the scanner container on your cloud.

Show me where API scanning is required for Fedramp

Fedramp issued the following guidance: https://www.fedramp.gov/assets/resources/documents/CSP_Vulnerability_Scanning_Requirements.pdf

Which includes: "All web interfaces and services (or approved sampling percentage) must be scanned".

Most applications are exposed as WebApplications, MobileApplications and Services that are consumed through APIs. The API layer is the common building block for all of these applications. The major struggle with webapp and mobileapp scanning is they do not fully cover data access vulnerabilities (OWASP top 10) specially role and tenant data access control.  The only way to provide this scanning is running business logic validation at the API layer. Our customers eliminate unnecessary web/mobile app scan and instead use the API scan reports to show controls.   

Can we show you a API penetration report custom to your API?

We are looking at Zaproxy. Please compare APIsec to it.

Zaproxy is a free tool from OWASP. As the name suggests it acts as a proxy for API calls. Exercising the API is something that a human would do to go through the Zap proxy. Creating the scenarios to uncover vulnerabilities is something a human would do. Interpreting the results of the Zaproxy is something a human would do. As the config changes or the API changes a human would have to keep up with zaproxy to ensure full coverage.

Compare that to APIsec. We are fully automated. We keep up with the API (no human). We create the scenarios, called categories (no human), we run the tests (no human), we interpret the results (no human).

So if an organization has security experts that will be dedicated to keeping up with the API, researching the market to understand scenarios, and running these tests as fast as developers change or modify application code then that is the equivalent.

BTW: Did I mention Apisec is a 3rd proof of security with our automated Pen test reporting. Most organizations need a 3rd party proof of security. You can not get that with Zaproxy.

Overview

We have found that allowing our staff to work in a fully flexible way is key to successful remote working. We trust our team to maximize their time and use techniques that are idiosyncratic to them.

Get Started

We trust our team to maximize their time and use techniques that are idiosyncratic to them.

  1. Create a Shopify account
  2. Create a Collection for your products in Webflow
  3. Add your products from Shopify

We have found that allowing our staff to work in a fully flexible way is key to successful remote working.

Events and actions

We trust our team to maximize their time and use techniques that are idiosyncratic to them.

  • You’ve been UI Designer for 2+ years.
  • You’ll ensure content strategy and design are perfectly in-sync.
  • Design and implementation of data storage solutions.

We trust our team to maximize their time and use techniques that are idiosyncratic to them.

Documentation

To set this up on your site, you’ll need a Shopify account and a few items to sell. Once you’ve done that, you’ll be ready for step 2.