๐๐ฎ๐ฟ๐ฑ๐ฒ๐ป๐ถ๐ป๐ด ๐๐ฃ๐ ๐ฆ๐ฐ๐ฎ๐ป ๐๐ผ๐๐ป๐ฑ๐ฎ๐ฟ๐ถ๐ฒ๐
API security is not just about protecting a database. When an API can scan local files, extract ZIP archives, and run heavy LLM tasks, the attack surface grows fast.
I recently worked on hardening the skill-scanner repository. I did not rely on gut feeling. I used a code graph tool called sqry to map out exactly how data flows through the system.
The goal was simple: stop a single API request from turning into arbitrary filesystem access or a resource exhaustion attack.
Here is how I approached the hardening process:
- Use a code graph to find real entry points.
- Apply limits to shared code, not just the API router.
- Ensure the system fails closed by default.
- Document security controls as part of the configuration.
The most important lesson came from the graph. A manual read might focus on the API router. However, the graph showed that the "SkillLoader" had 92 direct callers across the CLI, API, and tests.
If you only fix the API, you leave 91 other paths open. I moved the security boundaries down into the core loader so every caller stays within safe limits.
Specific changes I implemented:
- Path Validation: The API now rejects any path unless it resides within a pre-configured allowed root.
- Archive Safety: Uploaded files are written to a generic temporary name to prevent filename-controlled attacks. I added checks for ZIP member counts, file sizes, and symlinks.
- Resource Caps: I added hard limits for directory traversal, batch scan candidates, and LLM consensus runs.
- Authentication: All scan endpoints now require an API key.
- Rate Limiting: Added process-local rate limiting to prevent endpoint abuse.
Stop reviewing code by looking at one file at a time. Use text search for strings, but use AST and graph search to understand structure.
If a piece of code is shared, its security limits must be shared too.
Optional learning community: https://t.me/GyaanSetuAi