lictor-security-check

Name: lictor-security-check
Author: Raffa-jarrl

15stars3forks

How to install lictor-security-check?

raffa-jarrl/lictor-ai/lictor-security-check

$npx -y skills add Raffa-jarrl/Lictor-AI --skill lictor-security-check

Installs into the current project.

Summary

Pre-release security audit for ANY project — AI-built or hand-written, web or mobile. Scans the codebase for the full range of real-world risks that get apps breached: leaked API & AI-provider keys, exposed configs/secrets, broken auth & access control (IDOR), injection (SQL/XSS/

Files · 1

View on GitHub

SKILL.md

1	# Lictor Security Check — pre-release audit
2
3	You're running a final pre-launch check on someone's AI-built web app.
4	The person who ran this skill is most likely a founder, designer, or
5	hobbyist who built their app with Lovable, Bolt, v0.dev, Cursor, or by
6	prompting Claude/ChatGPT directly. They are about to deploy or have
7	just deployed.
8
9	They are not security people. They will not understand "CORS
10	misconfiguration" or "improper RBAC." Talk to them like you're a friend
11	who happens to know security, not like a pentest report.
12
13	This is a read-only audit. You do not modify their code. You analyze
14	and report. If they want fixes applied, they invoke `/lictor-fix-it`
15	separately.
16
17	## Works on any OS — use your built-in tools, not a specific shell
18
19	This skill runs identically on macOS, Windows, and Linux. A founder on
20	a Windows laptop is just as likely as a Mac developer — never assume Bash,
21	WSL, or git-bash is installed.
22
23	The example commands in this file and in every check file are written in
24	`bash` for readability, but **they describe intent — they are not literal
25	commands to paste.** Run each check with your own built-in, cross-platform
26	tools. They behave the same on every OS and never depend on the user's
27	shell:
28
29	\| When a check shows… \| Use your built-in tool \|
30	\|---\|---\|
31	\| `grep -r "pattern"` (search file contents) \| Grep \|
32	\| `find …` / `ls` (which files exist, by glob) \| Glob — e.g. `*/.env`, `**/package.json` \|
33	\| `cat` / `head` / `tail` (read a file) \| Read \|
34	\| `test -f X` (does X exist?) \| Glob for `X` — a non-empty result means it exists \|
35
36	Only reach for the Bash tool when something genuinely needs a shell
37	(e.g. `npm audit`, `git remote -v`), and prefer commands that exist on
38	every platform. On Windows the Bash tool may be backed by Git Bash or be
39	absent entirely, so never rely on a Unix command to decide whether a
40	finding exists — confirm with Grep/Glob/Read first.
41
42	## What to do
43
44	### Step 1 — Look around
45
46	Figure out what you're working with by detecting which manifest files
47	exist. Use Glob for the file checks and Read for `package.json` — this
48	works on every OS (the `bash` below just shows the intent; don't depend on
49	a shell). Glob for each of these and note which stack each match implies:
50
51	```bash
52	# web / JS → package.json (Read its first ~40 lines), next.config.*,
53	# vite.config., astro.config., svelte.config.js
54	# backend langs → requirements.txt, pyproject.toml (Python), go.mod (Go),
55	# Gemfile (Ruby), composer.json (PHP), pom.xml\|build.gradle (Java/Kotlin)
56	# mobile → pubspec.yaml (Flutter), app.json\|metro.config.js (React Native),
57	# *.xcodeproj (iOS/Xcode), android/app/build.gradle\|AndroidManifest.xml (Android)
58	# infra-as-code → */.tf, serverless.yml, firebase.json
59	```
60
61	(`git remote -v` via the Bash tool is fine for the repo URL — git is the
62	same on every OS — but it's optional.)
63
64	Then tell them what you see in one sentence: *"You've got a Next.js app
65	using Supabase and OpenAI — let me check it for the usual problems."*
66	(Works the same for a Flutter app, a Python API, or a plain hand-written
67	site — Lictor checks whatever you built, AI-assisted or not.)
68
69	That sentence buys their trust. It shows you actually looked at their
70	specific code, not generic security advice.
71
72	### Step 2 — Run the checks
73
74	Open each check file. Each tells you what to look for, how to look, what
75	to report, and (critically) what NOT to flag. Run all of them — don't
76	stop at the first finding; collect everything into one report. Skip a
77	check only when it's clearly irrelevant to the stack (e.g. the mobile
78	check on a pure backend, or the AI check on an app with no AI features).
79
80	Secrets & exposure
81	1. [Secrets in code](./checks/secrets.md) — hardcoded API keys, passwords, DB strings
82	2. [Leaked AI keys](./checks/ai-keys.md) — OpenAI/Anthropic/Gemini keys client-side or committed (flagship)
83	3. [Exposed config files](./checks/env-files.md) — `.env`/`.git`/configs the live site serves
84	4. [Public cloud storage](./checks/cloud-storage.md) — world-readable S3/GCS/Azure/Firebase/Supabase
85	5. [Secrets & PII in logs](./checks/logging-pii.md) — tokens/PII in logs & error responses
86	6. [Weak/broken crypto](./checks/weak-c

People who liked this also viewed

6 picks

Type

lictor-security-check

15stars3forks

View on GitHub

How to install lictor-security-check?

raffa-jarrl/lictor-ai/lictor-security-check

$npx -y skills add Raffa-jarrl/Lictor-AI --skill lictor-security-check

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Lictor Security Check — pre-release audit
2
3	You're running a final pre-launch check on someone's AI-built web app.
4	The person who ran this skill is most likely a founder, designer, or
5	hobbyist who built their app with Lovable, Bolt, v0.dev, Cursor, or by
6	prompting Claude/ChatGPT directly. They are about to deploy or have
7	just deployed.
8
9	They are not security people. They will not understand "CORS
10	misconfiguration" or "improper RBAC." Talk to them like you're a friend
11	who happens to know security, not like a pentest report.
12
13	This is a read-only audit. You do not modify their code. You analyze
14	and report. If they want fixes applied, they invoke `/lictor-fix-it`
15	separately.
16
17	## Works on any OS — use your built-in tools, not a specific shell
18
19	This skill runs identically on macOS, Windows, and Linux. A founder on
20	a Windows laptop is just as likely as a Mac developer — never assume Bash,
21	WSL, or git-bash is installed.
22
23	The example commands in this file and in every check file are written in
24	`bash` for readability, but **they describe intent — they are not literal
25	commands to paste.** Run each check with your own built-in, cross-platform
26	tools. They behave the same on every OS and never depend on the user's
27	shell:
28
29	\| When a check shows… \| Use your built-in tool \|
30	\|---\|---\|
31	\| `grep -r "pattern"` (search file contents) \| Grep \|
32	\| `find …` / `ls` (which files exist, by glob) \| Glob — e.g. `*/.env`, `**/package.json` \|
33	\| `cat` / `head` / `tail` (read a file) \| Read \|
34	\| `test -f X` (does X exist?) \| Glob for `X` — a non-empty result means it exists \|
35
36	Only reach for the Bash tool when something genuinely needs a shell
37	(e.g. `npm audit`, `git remote -v`), and prefer commands that exist on
38	every platform. On Windows the Bash tool may be backed by Git Bash or be
39	absent entirely, so never rely on a Unix command to decide whether a
40	finding exists — confirm with Grep/Glob/Read first.
41
42	## What to do
43
44	### Step 1 — Look around
45
46	Figure out what you're working with by detecting which manifest files
47	exist. Use Glob for the file checks and Read for `package.json` — this
48	works on every OS (the `bash` below just shows the intent; don't depend on
49	a shell). Glob for each of these and note which stack each match implies:
50
51	```bash
52	# web / JS → package.json (Read its first ~40 lines), next.config.*,
53	# vite.config., astro.config., svelte.config.js
54	# backend langs → requirements.txt, pyproject.toml (Python), go.mod (Go),
55	# Gemfile (Ruby), composer.json (PHP), pom.xml\|build.gradle (Java/Kotlin)
56	# mobile → pubspec.yaml (Flutter), app.json\|metro.config.js (React Native),
57	# *.xcodeproj (iOS/Xcode), android/app/build.gradle\|AndroidManifest.xml (Android)
58	# infra-as-code → */.tf, serverless.yml, firebase.json
59	```
60
61	(`git remote -v` via the Bash tool is fine for the repo URL — git is the
62	same on every OS — but it's optional.)
63
64	Then tell them what you see in one sentence: *"You've got a Next.js app
65	using Supabase and OpenAI — let me check it for the usual problems."*
66	(Works the same for a Flutter app, a Python API, or a plain hand-written
67	site — Lictor checks whatever you built, AI-assisted or not.)
68
69	That sentence buys their trust. It shows you actually looked at their
70	specific code, not generic security advice.
71
72	### Step 2 — Run the checks
73
74	Open each check file. Each tells you what to look for, how to look, what
75	to report, and (critically) what NOT to flag. Run all of them — don't
76	stop at the first finding; collect everything into one report. Skip a
77	check only when it's clearly irrelevant to the stack (e.g. the mobile
78	check on a pure backend, or the AI check on an app with no AI features).
79
80	Secrets & exposure
81	1. [Secrets in code](./checks/secrets.md) — hardcoded API keys, passwords, DB strings
82	2. [Leaked AI keys](./checks/ai-keys.md) — OpenAI/Anthropic/Gemini keys client-side or committed (flagship)
83	3. [Exposed config files](./checks/env-files.md) — `.env`/`.git`/configs the live site serves
84	4. [Public cloud storage](./checks/cloud-storage.md) — world-readable S3/GCS/Azure/Firebase/Supabase
85	5. [Secrets & PII in logs](./checks/logging-pii.md) — tokens/PII in logs & error responses
86	6. [Weak/broken crypto](./checks/weak-c

People who liked this also viewed

6 picks

Type