awesome-leak-audit

Solid

Audit a public-facing client (browser extension, mobile/desktop app, SPA, CLI, SDK, or any open-sourced client that talks to a private backend) so its public surface stays self-contained and doesn't help attackers. Use when asked to review a repo for leaked backend internals, secrets, or abuse-enabling disclosure; to check that comments/docs/tests don't reveal server-side mechanics (rate limits, anti-abuse, quotas, test backdoors, infra/tech stack, DB/schema, env-var names); to scrub a client before open-sourcing or a store/app-store submission; or for client-side security hardening (permissions, IPC/message sender validation, auth-token handling, DOM/XSS sinks, build-time config, secret bundling). Triggers: 'audit for leaks', 'does this leak backend details', 'is this safe to make public', 'security review of the client/extension', 'what does our API disclose', 'harden the client'.

Code & Development 2 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
16
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Public Client Leak Audit Audit a **public** client codebase that talks to a **private** backend. Goal: the public surface must be *self-contained* — it may reveal the calls it makes and the data shapes it exchanges (unavoidable for any shipped client), but nothing beyond that. Every extra detail about how the server works is free reconnaissance for an attacker and a lever for abuse. This skill produces three things: a **findings list** (leaks + client-side security holes, each with `file:line` and severity), a set of **applied fixes**, and a **report** with residual recommendations. **Reference files** (load on demand — read the one you need, don't inline all of them): - [`references/leak-taxonomy.md`](references/leak-taxonomy.md) — the categories of disclosure to hunt, why each matters, and starter search patterns. - [`references/rewrite-rules.md`](references/rewrite-rules.md) — the comment/string rewrite rule with before/after examples; how to decide keep-vs-cut. - [`references/client-hardening.md`](references/client-hardening.md) — client-side security checklist (permissions, IPC, tokens, DOM, network, build config, supply chain). - [`references/report-template.md`](references/report-template.md) — the output report structure. - [`scripts/leak-sweep.sh`](scripts/leak-sweep.sh) — a parameterized ripgrep sweep to seed the search (customize the pattern arrays per product). ## The core mental model Sort every disclosure into one of two buckets: - **Necessary-minimum** ...

Details

Author
khasky
Repository
khasky/awesome-agent-skills
Created
4 months ago
Last Updated
today
Language
Python
License
MIT

Integrates with

OpenAI · AI

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

public-client-leak-audit

Audit a public-facing client (browser extension, mobile/desktop app, SPA, CLI, SDK, or any open-sourced client that talks to a private backend) so its public surface stays self-contained and doesn't help attackers. Use when asked to review a repo for leaked backend internals, secrets, or abuse-enabling disclosure; to check that comments/docs/tests don't reveal server-side mechanics (rate limits, anti-abuse, quotas, test backdoors, infra/tech stack, DB/schema, env-var names); to scrub a client before open-sourcing or a store/app-store submission; or for client-side security hardening (permissions, IPC/message sender validation, auth-token handling, DOM/XSS sinks, build-time config, secret bundling). Triggers: 'audit for leaks', 'does this leak backend details', 'is this safe to make public', 'security review of the client/extension', 'what does our API disclose', 'harden the client'.

2 Updated today
khasky
Code & Development Solid

awesome-security-audit

Audits code for common vulnerabilities: injection, secrets, auth, and dependency CVEs — with confidence-gated, evidence-backed findings mapped to CWE/OWASP. Use when reviewing security, before a release, after adding auth/payments/sensitive-data handling, or when the user says 'security review', 'security audit', 'check for vulnerabilities', 'is this secure'. Do not use for auditing what a public client discloses about a private backend — use awesome-leak-audit for that.

2 Updated today
khasky
Data & Documents Listed

security-audit

Audit the app's security surface — authentication, authorization and tenant isolation, transport/CSRF/cookies, injection and SSRF, uploads and storage, secrets and logging, the CI security tooling, and public-repo disclosure risk (code whose secrecy is load-bearing) — against a maintained criteria list, and periodically refresh that list from current threats. Use when asked for a security audit/review, a pentest-style pass, or to find and close security holes, and before opening public registration. Defensive only: finds weaknesses to fix them, never to weaponize; a confirmed live hole is disclosed privately. Composes with the built-in /security-review and CodeQL rather than duplicating them. Produces a ranked report; files issues only with your approval.

0 Updated today
ChulioZ