sast-hardcodedsecrets

Name: sast-hardcodedsecrets
Author: utkusen

36installs56forks

How to install sast-hardcodedsecrets?

utkusen/sast-skills/sast-hardcodedsecrets

$npx -y skills add utkusen/sast-skills --skill sast-hardcodedsecrets

Installs into the current project.

Summary

Detect hardcoded sensitive data (API keys, access tokens, private keys, passwords, etc.) in publicly accessible code — frontend JavaScript, mobile apps, client-side bundles, and HTML templates. Uses a three-phase approach: recon (find secret candidates), batched verify (confirm r

Files · 1

View on GitHub

SKILL.md

1	# Hardcoded Secrets in Public Code Detection
2
3	You are performing a focused security assessment to find hardcoded sensitive data that is exposed in publicly accessible code. This skill uses a three-phase approach with subagents: recon (find all potential secret candidates), batched verify (confirm each is a real secret in publicly reachable code, in parallel batches of 3), and merge (consolidate batch reports into one file).
4
5	Prerequisites: `sast/architecture.md` must exist. Run the analysis skill first if it doesn't.
6
7	---
8
9	## What Are Hardcoded Secrets in Public Code
10
11	Hardcoded secrets are sensitive credentials — API keys, access tokens, private keys, passwords, signing secrets, database connection strings — embedded directly in source code as string literals.
12
13	This skill focuses specifically on secrets that end up in publicly accessible code, meaning an attacker can extract them without any server-side access. A secret hardcoded in backend server code is bad practice but not directly exploitable by an external attacker inspecting the deployed application. A secret hardcoded in frontend JavaScript or a mobile app binary is directly extractable.
14
15	The core question: Can an external attacker obtain this secret from the deployed application without server access?
16
17	### What to Report (Publicly Accessible Code)
18
19	These code paths are accessible to attackers after deployment:
20
21	- Frontend JavaScript/TypeScript — any `.js`, `.ts`, `.jsx`, `.tsx` file that runs in the browser. This includes:
22	- React, Angular, Vue, Svelte components and pages
23	- Next.js client components (files with `"use client"` or files under `app/` without `"use server"`)
24	- Nuxt.js pages and client plugins
25	- Vanilla JS in `public/`, `static/`, or `assets/` directories
26	- Webpack/Vite/Rollup entry points and their imported modules
27	- Any file imported by a client-side entry point (even if it lives in a `utils/` or `lib/` folder)
28	- Mobile application code — extractable via reverse engineering (decompiling APK, inspecting IPA):
29	- Android: Java/Kotlin source files
30	- iOS: Swift/Objective-C source files
31	- React Native: JavaScript bundles
32	- Flutter: Dart source files
33	- Xamarin: C# source files
34	- HTML files and templates served to clients — inline `<script>` blocks, `data-` attributes, meta tags
35	- Client-side configuration files — files in `public/`, `static/`, `assets/`, `www/` directories
36	- Electron/desktop app source — extractable from ASAR archives
37	- WebAssembly source/companion JS — secrets in JS glue code or extractable from WASM
38
39	### What NOT to Report (Backend-Only Code)
40
41	Do not flag secrets in these locations — they are not publicly accessible:
42
43	- Server-side application code — Express route handlers (server-only), Django views, Flask routes, Spring controllers, Rails controllers, Go HTTP handlers, PHP controllers — code that runs exclusively on the server
44	- Server-side API route files — Next.js `app/api/` routes, Nuxt server routes, SvelteKit `+server.ts` files
45	- Environment files — `.env`, `.env.local`, `.env.production` (unless served statically)
46	- Server-side configuration — `config/database.yml`, `settings.py`, `application.properties`, `appsettings.json`
47	- CI/CD pipeline files — `.github/workflows/`, `Jenkinsfile`, `.gitlab-ci.yml`
48	- Docker/infrastructure files — `Dockerfile`, `docker-compose.yml`, Kubernetes manifests
49	- Backend utility/service files — files that are only imported by server-side code
50	- Test files — test fixtures and test configuration (unless the test files are shipped to the client)
51	- Migration files — database migrations
52
53	### Distinguishing Frontend from Backend
54
55	This is critical and requires understanding the project architecture:
56
57	Next.js: Files under `app/` with `"use client"` directive or without `"use server"` are client components. Files under `app/api/` are server-only. Files under `pages/api/` are server-only. Files under `pages/` (non-api) render on both server and client — secrets here ARE exposed. `next.config.js` runs server-side only but `NEXT_PUBLIC_*` env vars are embedded in client bundles.
58
59	Nuxt.js: Files under `pages/`, `components/`, `composables/` are client-accessible. Files under `server/` are server-only.
60
61	React (CRA/Vite): Everything in `src/` is bundled fo

People who liked this also viewed

6 picks

Type

sast-hardcodedsecrets

36installs56forks

View on GitHub

How to install sast-hardcodedsecrets?

utkusen/sast-skills/sast-hardcodedsecrets

$npx -y skills add utkusen/sast-skills --skill sast-hardcodedsecrets

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Hardcoded Secrets in Public Code Detection
2
3	You are performing a focused security assessment to find hardcoded sensitive data that is exposed in publicly accessible code. This skill uses a three-phase approach with subagents: recon (find all potential secret candidates), batched verify (confirm each is a real secret in publicly reachable code, in parallel batches of 3), and merge (consolidate batch reports into one file).
4
5	Prerequisites: `sast/architecture.md` must exist. Run the analysis skill first if it doesn't.
6
7	---
8
9	## What Are Hardcoded Secrets in Public Code
10
11	Hardcoded secrets are sensitive credentials — API keys, access tokens, private keys, passwords, signing secrets, database connection strings — embedded directly in source code as string literals.
12
13	This skill focuses specifically on secrets that end up in publicly accessible code, meaning an attacker can extract them without any server-side access. A secret hardcoded in backend server code is bad practice but not directly exploitable by an external attacker inspecting the deployed application. A secret hardcoded in frontend JavaScript or a mobile app binary is directly extractable.
14
15	The core question: Can an external attacker obtain this secret from the deployed application without server access?
16
17	### What to Report (Publicly Accessible Code)
18
19	These code paths are accessible to attackers after deployment:
20
21	- Frontend JavaScript/TypeScript — any `.js`, `.ts`, `.jsx`, `.tsx` file that runs in the browser. This includes:
22	- React, Angular, Vue, Svelte components and pages
23	- Next.js client components (files with `"use client"` or files under `app/` without `"use server"`)
24	- Nuxt.js pages and client plugins
25	- Vanilla JS in `public/`, `static/`, or `assets/` directories
26	- Webpack/Vite/Rollup entry points and their imported modules
27	- Any file imported by a client-side entry point (even if it lives in a `utils/` or `lib/` folder)
28	- Mobile application code — extractable via reverse engineering (decompiling APK, inspecting IPA):
29	- Android: Java/Kotlin source files
30	- iOS: Swift/Objective-C source files
31	- React Native: JavaScript bundles
32	- Flutter: Dart source files
33	- Xamarin: C# source files
34	- HTML files and templates served to clients — inline `<script>` blocks, `data-` attributes, meta tags
35	- Client-side configuration files — files in `public/`, `static/`, `assets/`, `www/` directories
36	- Electron/desktop app source — extractable from ASAR archives
37	- WebAssembly source/companion JS — secrets in JS glue code or extractable from WASM
38
39	### What NOT to Report (Backend-Only Code)
40
41	Do not flag secrets in these locations — they are not publicly accessible:
42
43	- Server-side application code — Express route handlers (server-only), Django views, Flask routes, Spring controllers, Rails controllers, Go HTTP handlers, PHP controllers — code that runs exclusively on the server
44	- Server-side API route files — Next.js `app/api/` routes, Nuxt server routes, SvelteKit `+server.ts` files
45	- Environment files — `.env`, `.env.local`, `.env.production` (unless served statically)
46	- Server-side configuration — `config/database.yml`, `settings.py`, `application.properties`, `appsettings.json`
47	- CI/CD pipeline files — `.github/workflows/`, `Jenkinsfile`, `.gitlab-ci.yml`
48	- Docker/infrastructure files — `Dockerfile`, `docker-compose.yml`, Kubernetes manifests
49	- Backend utility/service files — files that are only imported by server-side code
50	- Test files — test fixtures and test configuration (unless the test files are shipped to the client)
51	- Migration files — database migrations
52
53	### Distinguishing Frontend from Backend
54
55	This is critical and requires understanding the project architecture:
56
57	Next.js: Files under `app/` with `"use client"` directive or without `"use server"` are client components. Files under `app/api/` are server-only. Files under `pages/api/` are server-only. Files under `pages/` (non-api) render on both server and client — secrets here ARE exposed. `next.config.js` runs server-side only but `NEXT_PUBLIC_*` env vars are embedded in client bundles.
58
59	Nuxt.js: Files under `pages/`, `components/`, `composables/` are client-accessible. Files under `server/` are server-only.
60
61	React (CRA/Vite): Everything in `src/` is bundled fo

People who liked this also viewed

6 picks

Type