Skip to content
skillsafebeta
← Report library
Purpose / Development

Security And Hardening Skill Security Audit

What the author says it does (original text)

Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use wh

Independent security check

Security risks found

Files checked
1
Risks found
3
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

The suggested secret check prints entire lines that may contain credentials

Source references: 1
What we found

The command greps staged diffs and directly prints lines containing password, secret, api_key, or token. If an agent, CI job, or logged terminal runs it, real credentials can enter session transcripts, model context, or build logs. It also covers only four textual patterns and cannot reliably detect differently named or formatted secrets.

Why this matters

Credentials may become visible to additional people or systems, while a clean result may give false confidence that the staged change contains no secret.

This is an actionable pre-commit check, not merely a negative example. It pipes the staged diff to `grep` without a quiet option, so matching lines are printed; if a line contains a real credential, an agent session, CI log, or terminal history may retain it. The four name patterns are also incomplete as secret detection. Users can ask for a redacting scanner that reports only filenames/status and restrict log retention.

SKILL.md:370In the instructionsOpen original file
**Always check before committing:**```bash# Check for accidentally staged secretsgit diff --cached | grep -i "password\|secret\|api_key\|token"```
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
Medium risk

The access-control example passes an unallowlisted request body into the update service

Source references: 2
What we found

After checking resource ownership, the example passes the entire req.body to taskService.update. Ownership checking does not prevent mass assignment; if the service accepts ownerId, status, privilege, or other sensitive fields, the caller may alter properties the endpoint was not meant to expose.

Why this matters

An attacker could potentially transfer ownership, change protected state, or modify other sensitive fields.

The example checks resource ownership but then passes the entire `req.body` to the update service without showing an allowlist or update-specific schema. If the service accepts sensitive properties such as `ownerId`, permissions, or status, an authenticated owner could mass-assign fields the endpoint should not expose. The impact depends on the omitted service implementation, so this is a plausible example-level risk, not proof of a vulnerability. Users can require explicit selection of permitted fields.

SKILL.md:134In the instructionsOpen original file
// Always check authorization, not just authenticationapp.patch('/api/tasks/:id', authenticate, async (req, res) => {  const task = await taskService.findById(req.params.id);  // Check that the authenticated user owns this resource  if (task.ownerId !== req.user.id) {    return res.status(403).json({      error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }    });  }  // Proceed with update  const updated = await taskService.update(req.params.id, req.body);  return res.json(updated);
Show 1 other places
SKILL.md:133In the instructionsOpen original file
```typescript// Always check authorization, not just authenticationapp.patch('/api/tasks/:id', authenticate, async (req, res) => {  const task = await taskService.findById(req.params.id);  // Check that the authenticated user owns this resource  if (task.ownerId !== req.user.id) {    return res.status(403).json({      error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }    });  }  // Proceed with update  const updated = await taskService.update(req.params.id, req.body);  return res.json(updated);
Medium risk

The upload example primarily trusts the MIME declaration and makes content-signature checks optional

Source references: 1
What we found

The example checks only file.mimetype and size, while recommending magic-byte checks only “if critical.” An uploader can commonly falsify the declared type; if this is treated as complete validation, non-image content may pass under an allowed image MIME type.

Why this matters

A disguised file could enter storage and attack processing components or users when it is decoded, transformed, downloaded, or displayed.

This recommended upload-validation example enforces only the client-controllable `file.mimetype` and size; magic-byte inspection is described as necessary only “if critical,” not as the default. If treated as complete protection, an attacker could label non-image content with an allowed MIME type and pass this function. Consequences depend on how the file is stored, parsed, and served. Users can ask for mandatory content-signature validation and safe image re-encoding.

SKILL.md:257In the instructionsOpen original file
```typescript// Restrict file types and sizesconst ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];const MAX_SIZE = 5 * 1024 * 1024; // 5MBfunction validateUpload(file: UploadedFile) {  if (!ALLOWED_TYPES.includes(file.mimetype)) {    throw new ValidationError('File type not allowed');  }  if (file.size > MAX_SIZE) {    throw new ValidationError('File too large (max 5MB)');  }  // Don't trust the file extension — check magic bytes if critical}```
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

This Skill is defensive development guidance. It asks the agent to identify trust boundaries, assets, and abuse cases before applying controls; no executable script is included.

View source
SKILL.md:21In the instructionsOpen original file
## Process: Threat Model FirstControls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:1. **Map the trust boundaries.** Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and **LLM output** — plus the local values that look internal because the OS handed them to you: another process's command line or environment, filenames on a shared volume, a path in a job payload. Trust follows who *wrote* a value, not which channel delivered it. Every boundary is attack surface.2. **Name the assets.** What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.3. **Run STRIDE over each boundary** — a quick lens, not a ceremony:

The guidance requires prior human approval for high-impact changes involving authentication, sensitive data, external services, CORS, uploads, rate limits, and elevated privileges.

View source
SKILL.md:55In the instructionsOpen original file
### Ask First (Requires Human Approval)- Adding new authentication flows or changing auth logic- Storing new categories of sensitive data (PII, payment info)- Adding new external service integrations- Changing CORS configuration- Adding file upload handlers- Modifying rate limiting or throttling- Granting elevated permissions or roles

The guidance explicitly treats model output and prompt context as untrusted, and calls for scoped agent permissions plus confirmation for destructive actions.

View source
SKILL.md:403In the instructionsOpen original file
- **Treat all model output as untrusted input (LLM05: Improper Output Handling).** Never pass LLM output straight into `eval`, SQL, a shell, `innerHTML`, or a file path. Validate and encode it exactly as you would raw user input.- **Assume prompts can be hijacked (LLM01: Prompt Injection).** Untrusted text in the context window — a user message, a fetched web page, a PDF — can carry instructions. The system prompt is not a security boundary; enforce permissions in code, not in the prompt.- **Keep secrets and other users' data out of prompts (LLM02 / LLM07).** Anything in the context can be echoed back. Don't put API keys, cross-tenant data, or the full system prompt where the model can repeat it.- **Constrain tool and agent permissions (LLM06: Excessive Agency).** Scope tools to the minimum, require confirmation for destructive or irreversible actions, and validate every tool argument.- **Bound consumption (LLM10: Unbounded Consumption).** Cap tokens, request rate, and loop/recursion depth so a crafted input can't run up cost or hang the system.- **Isolate retrieval data (LLM08: Vector and Embedding Weaknesses).** In RAG, treat the vector store as a trust boundary: partition embeddings per tenant so one user can't retrieve another's data, and validate documents before indexing so poisoned content can't steer answers.

The guide acknowledges that its SSRF example retains a race between DNS validation and connection, and recommends address pinning or a filtering agent for high-risk cases.

View source
SKILL.md:220In the instructionsOpen original file
**Caveat — this still has a TOCTOU gap.** `fetch` resolves DNS again after the check, so an attacker using a short-TTL record can rebind to an internal IP between validation and connection. For high-risk surfaces, resolve once and connect to the pinned IP, or put a filtering agent in front (`request-filtering-agent` / `ssrf-req-filter`).
Start here · InstructionsSKILL.md
security-and-hardening
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 8 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Read keys or account settings
SKILL.md:26In the instructionsOpen original file
1. **Map the trust boundaries.** Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and **LLM output** — plus the local values that look internal because t …2. **Name the assets.** What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.3. **Run STRIDE over each boundary** — a quick lens, not a ceremony:
SKILL.md:104In the instructionsOpen original file
app.use(session({  secret: process.env.SESSION_SECRET,  // From environment, not code  resave: false,
SKILL.md:170In the instructionsOpen original file
app.use(cors({  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:3000',  credentials: true,
Connect to websites
SKILL.md:170In the instructionsOpen original file
app.use(cors({  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:3000',  credentials: true,
SKILL.md:195In the instructionsOpen original file
// BAD: fetch whatever the user gives youawait fetch(req.body.webhookUrl);
SKILL.md:215In the instructionsOpen original file
await fetch(await assertSafeUrl(req.body.webhookUrl), { redirect: 'error' });```
Run commands
SKILL.md:371In the instructionsOpen original file
**Always check before committing:**```bash# Check for accidentally staged secrets
Lines read
525
File checksum (to compare versions)
23f960d6610b50c24380b3be1ecb610eade1584fd25c3c88016eea76ff6f9f02