apiclarity
cats
apiclarity | cats | |
---|---|---|
9 | 22 | |
475 | 1,092 | |
1.5% | 1.1% | |
3.4 | 9.8 | |
17 days ago | 6 days ago | |
Go | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
apiclarity
-
Two approaches to make your APIs more secure
We'll install APIClarity into a Kubernetes cluster to test our API documentation. We're using a Kind cluster for demonstration purposes. Of course, if you have another Kubernetes cluster up and running elsewhere, all steps also work there.
-
How to Get Started with Open Source
If you go to APIClarity, the first thing you’ll see is the source code (Figure 1), followed by some documentation at the bottom.
-
Risk scoring your API Specification with Panoptica
This feature is available in the open-source tool APIClarity, as part of the OpenClarity initiative.
-
Show HN: Mitmproxy2swagger – Automagically reverse-engineer REST APIs
Hi, I would also like to add another tool I'm contributing to at work (cisco) called APIClarity [1]. It aims at reconstructing swagger specifications of REST microservices running in K8S, but can also be run locally.
This is a challenging task and we don't support OpenAPI v3 specs yet (we are working on it).
Feel free to have a look, and get ideas from it :)
We'll also be presenting it at next Kubecon 2022.
[1]: https://github.com/openclarity/apiclarity
- Microservices API challenges
-
How to Use OpenAPI for Secure and Robust API Integration
For example, APIClarity is a tool that observes all of the API traffic within your Kubernetes environment. Based on traffic observation, APIClarity infers an OpenAPI description for those APIs. This is especially helpful if the API creator never defined or provided such a description. It also surfaces potential problems with existing APIs, such as requests made to undocumented, shadow APIs or continued use of deprecated, zombie APIs. If you’re getting started on the path toward OAS compliance, then tools like APIClarity can be a great source of insight and observability.
-
Watching the Requests Go By: Reconstructing an API Spec with APIClarity
The fundamental first step to solving this problem is to create an API spec and use it to audit and document the APIs your apps use. Ideally, we would create an API spec simply by observing API traffic in real-world applications. In the past, there was no simple, scalable, and open-source tooling capable of doing this. Now, we have APIClarity—an open-source API traffic visibility tool for Kubernetes (K8s) clusters. It’s purpose-built to address the gap and enable API reconstruction through observation.
- Reconstruct Open API Specifications from real-time workload traffic seamlessly
cats
- Ask HN: What Underrated Open Source Project Deserves More Recognition?
- Yet Another REST API Fuzzer
-
CWE Top Most Dangerous Software Weaknesses
Out of this frustration I've built: https://github.com/Endava/cats. It's for APIs, but mostly addressing exactly this case: don't use strings for everything, if you choose to use it though, make sure you add patterns for checking if things are valid, make sure you think about all the corner cases and all the weird characters that can brake you app, and so on.
-
API Security Testing
If the API has an OpenAPI spec available, you can use: https://github.com/Endava/cats
-
Cucumber Maintainer out of Job and future of the project is uncertain
This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.
-
Invisible Characters
I've built a tool specifically to test if these kind of characters will reach API backends: https://github.com/Endava/cats. My idea was that APIs should explicitly reject or sanitise input containing such characters.
- REST API fuzzer with minimum configuration
- Learnings from 5 Years of Tech Startup Code Audits
-
ce framework pentru fuzzing folositi ?
Cats by Endava
- am creat un web server in C imun la buffer overflows
What are some alternatives?
oasdiff - OpenAPI Diff and Breaking Changes
openapi-fuzzer - Black-box fuzzer that fuzzes APIs based on OpenAPI specification. Find bugs for free!
Nacos - an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.
restler-fuzzer - RESTler is the first stateful REST API fuzzing tool for automatically testing cloud services through their REST APIs and finding security and reliability bugs in these services.
api-firewall - Fast and light-weight API proxy firewall for request and response validation by OpenAPI specs.
mimic - [ab]using Unicode to create tragedy
microservices-demo - Deployment scripts & config for Sock Shop
RESTest - RESTest: Automated Black-Box Testing of RESTful Web APIs
kusk - CLI for Kusk Gateway related functionality
jcrapi2 - A Java Wrapper For Official Supercell Clash Royal Api
openapi-preprocessor - An authoring tool for OpenAPI specifications
mitmproxy2swagger - Automagically reverse-engineer REST APIs via capturing traffic