BLOG

Questions Answered: Let’s shift API security left – sure, but how?

You had questions, and we’ve got answers!

Thank you for all the questions submitted on our webinar: “Let’s shift API security left – sure, but how?” Below is the replay and all the answers to the questions that were asked. If you’d like more information please feel free to contact us.

 

[xyz-ihs snippet=”Webinar-Lets-Shift-API-Security-Left”]

 

Don’t the cloud service providers offer API discovery/inventory services?

API Discovery is provided by several vendors, both at design time and runtime. Runtime is notoriously more difficult as people use end to end HTTPs which exposes very limited data. It will become mostly impossible when TLS 1.3 is available. At design time, the most common way is to crawl code repositories to find API code/Swaggers/OAS files. In the end, the solution is to tackle the issue at the root and put proper governance in place. 

API inventory/governance is a core function of API management solutions and yes, most cloud service providers bring such solutions. 

 

How do you do a security audit for a private or hidden API via blackbox?

If you are talking about our security audit (which analyzes OAS files), we do not need access to the API itself. 

 

Is it true BitBucket now has security integrated? ie. BitBucket has DevSecOps?

Bitbucket pipelines certainly will play a role in a DevSecOps approach, since it allows to automate the execution of security tasks, such as our audit.

 

Is there any possibility of fixing these issues once found in runtime? Can all  those issues be fixed – I mean fixing by the tool itself?

I am afraid there is no magic. And if anybody tells you otherwise, be careful. The problems tools like ours find at *runtime* have deep roots in the code itself and will require the code to be fixed, for example adding validation logic or fine-grained authorization logic.

 

How do you do API security testing on the rate limit part of cloud API?

Tools like Gatling will help you there. See this good article on rate limiting: https://nordicapis.com/everything-you-need-to-know-about-api-rate-limiting

 

Do you recommend SAST scanning APIs individually, the mesh of the APIs, or both?

SAST is done at the code level, so I am not sure what you mean by SAST analysis of the mesh of APIs (as a whole). Ping us (support.42crunch.com) if you want to refine this question.

 

 

 

Try our security audit for free. If you want to see the whole platform in action, request a demo now!

Latest Resources

WEBINAR

Webinar Series - Defending APIs with Jim Manico

Defending APIs with Jim Manico – Episode 1

Episode 1: Request Forgery on the Web – CSRF & SSRF

November 10, 2022 | 9am PST | 5pm BST

Join Jim Manico, CEO of Manicode and Colin Domoney from 42Crunch, as they deliver a 2-part webinar series to help developers better defend APIs.

NEWS

42Crunch Announce OWASP Membership

42Crunch becomes a member of OWASP to Advance API Security 

By Newsdesk | November 14, 2022

November 14, 2022, San Francisco, CA –  42Crunch is pleased to announce our corporate membership of the Open Web Application Security Project (OWASP), a worldwide not-for-profit charitable organization focused on improving the security of software. At 42Crunch we have always been inspired by OWASP’s role as an enabler […]

DataSheet

Datasheet Cover Images P1-02

Product Datasheet Addressing API Security Challenges

APIs are the core building block of every enterprise’s digital strategy, yet they are also the number one attack surface for hackers. 42Crunch makes developers’ and security practitioners' lives easier by protecting APIs, with a platform that automates security into the API development pipeline and gives full oversight of security policy enforcement at every stage of the API lifecycle.

Ready to Learn More?

Developer-first solution for delivering API security as code.