You had questions, and we’ve got answers!
How do you find all the API endpoints in web applications?
A few ways that you can do that include:
- Finding all OpenAPI files in your source code repositories (these would be JSON and YAML file with predefined OpenAPI schema)
- Exporting API definitions from API gateways used by the company
- Looking at the deployments you have – for example, most likely each microservice in your Kubernetes is exposing an API
- Analyzing the client side (e.g. JavaScript) invoking the endpoints
- Using a proxy like ZAP, Burp, Fiddler, or Charles to see which endpoints are invoked
What do you think the main reason XSS is no longer exploited that much?
Cross-site scripting (XSS) attack happens when an attacker managers to get their Javascript code executed along with the main web application in client’s browser.
These days, it is less common because clients (mobile applications, single-page web applications, and so on) are not just rendering HTML, but actually have rich user interfaces that simply use data from APIs.
An XSS attack then becomes harder but is still potentially possible if the attacker managers to submit malicious script into an API and then have victim’s browser extract that malicious content from an API and render it.
Proper data validation on API inputs and outputs can mitigate this attack vector.
Could you please explain how to test the Mass Assignment in API’s?
If you can review the API implementation, see the code and make sure that it is not just blindly converting incoming JSON payloads into objects and writing them to the database.
Make sure that you strictly define schemas of API call payloads. Any calls with payloads that do not match the schema should get rejected.
Hello and thank you for great explanation and schema. Do you have any stats for each attacks? What % for each? (Based on your experience, no precise % or study)
It is very hard to give percentages. API vulnerabilities are quite often not disclosed and even if the actual breach gets disclosed, details are often very scant.
You are welcome to look through the weekly API vulnerability reports at APIsecurity.io to get a sense of the vulnerabilities that are more frequent.
Security Automation Questions
(1) What are the possibilities of having API security checks automated? Maybe in Pipeline? Some other way?
(2) Any recommendations on automated tools to help detect these vulnerabilities? Manually verifying all the API code being developed at an enterprise can be nearly impossible.
(3) Is there an automated tool which can scan our API and find out any possible vulnerability?
42Crunch has both static analysis of API definitions (Security Audit) and dynamic tests of conformance between API endpoint implementation and its definition (Conformance Scan).
Both can indeed be used in CI/CD pipeline to automate the tests.
So far we have been helping our enterprise customers implement this. We have done such implementations for GitHub Actions, Azure Pipelines, GitLab, Bamboo.
We are currently working on productizing these extensions to have them as ready-to-use extensions in the corresponding marketplaces.
Sometimes you find security is tested at the very end of API development. How can we control this behavior?
Effective security needs to be “shifted left”, that is: started early in the API design, implementation, and testing.
A good way to start would be to have developers perform security best practices checks on their API definitions using VS Code OpenAPI extension and online APISecurity.io Security Audit tool.
Then extend the automated tests (both static and dynamic) to your CI/CD pipeline with 42Crunch platform.
Besides tools like Burp Suite/OWASP Zap/Postman do you use any other tools for API security testing?
Definitely. See some links to tutorials on using Burp and Postman for API Security testing in: https://apisecurity.io/issue-34-owasp-launches-api-security-top-10-project/
General OWASP Questions
(1) How is the OWASP API security related to OWASP? I don’t see this information on owasp.org ?
(2) How can I contribute to the OWASP API Security Project? Which are the areas in which the contributions are expected as per the current project status.
(3) Which OWASP top 10 version are you referring to? Is it 2017?
OWASP API Security project only launched this year and as of right now is still in Release Candidate phase. When the project gets released later this year it will be OWASP API Security Top 10 2019.
Do you recommend following standard secure sdlc? requirements analysis/threat model/static/dynamic testing for APIs? and if so, how do you scale that with companies having 100s of APIs?
These days, companies frequently have hundreds or even thousands of APIs that keep constantly changing. The only way to control their security levels is to adopt sound DevSecOps tools and processes that would automatically perform security checks on each introduced or modified API.
Just as with the OWASP Top 10, it seems the API Top 10 is not an exhaustive list. If I as a developer use this as a checklist, I could still find myself vulnerable. Is there an initiative to educate API developers on the fundamental principles behind the Top 10?
API Security Checklist is on the roadmap of the OWASP API Security Top 10 project. However, that part of the work has not started yet – stay tuned.
Meanwhile, weekly newsletter at APISecurity.io does mention various community resources and alternative checklists when they get published.
What is the best source to know what is the state of the art authentication protocol and how to keep up with new ones?
IETF OAuth 2.0 Security Best Practices would be a good place to start: https://apisecurity.io/issue-42-http-security-headers/
Does GraphQL make an API more or less vulnerable to Excessive Data Exposure? Or does it just change the way that a developer has to protect the API?
Just like with REST, the key is to treat GraphQL APIs as products and ensure that only the data supposed to be accessible to users gets sent in responses.
A4 – Lack of resources and rate limiting – how to do rate limiting properly? by IP ? by username? by what condition?
Implement a limit on how often a client can call the API within a defined timeframe. For sensitive operations such as login or password reset, consider rate limits by API method (e.g., authentication), client (e.g., IP address), property (e.g., username).
Are all the vulnerabilities presented fixed by now?
Try our security audit for free. If you want to see the whole platform in action, request a demo now!
