Skip to content
Report library
Purpose / Other

API And Interface Design Skill Security Audit

What the author says it does (original text)

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

Independent security check

Security risks found

Files checked
1
Risks found
1
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.No risks found
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: 1
Medium risk

The absolute rule to trust internal and database data can bypass necessary validation

Source references: 3
What we found

The document calls for validation at system edges, but also says to trust internal code and not validate data from the application's own database. This equates origin with trustworthiness; invalid or tainted data already stored may receive no later checks.

Why this matters

A system following this rule could use malformed fields, malicious text, or stale-schema data in rendering, authorization, or other business decisions. Depending on usage, this could cause injection, incorrect authorization, or service failures.

The skill explicitly treats internal code and data read from the application's own database as not needing validation. Boundary validation is a reasonable default, but stored data can violate current constraints after legacy writes, faulty migrations, direct writes, or earlier bugs. Code following this absolute rule could trust polluted values and make incorrect authorization, rendering, or business decisions. Users can ask the author to make this invariant- and risk-based, retaining checks for sensitive operations, database reads, and schema migrations.

SKILL.md:88In the instructionsOpen original file
### 3. Validate at BoundariesTrust internal code. Validate at system edges where external input enters:
Show 2 other places
SKILL.md:120In the instructionsOpen original file
Where validation does NOT belong:- Between internal functions that share type contracts- In utility functions called by already-validated code- On data that just came from your own database
SKILL.md:112In the instructionsOpen original file
Where validation belongs:- API route handlers (user input)- Form submission handlers (user input)- External service response parsing (third-party data -- **always treat as untrusted**)- Environment variable loading (configuration)> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.
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 a guidance document for REST, GraphQL, TypeScript contracts, and module boundaries. Its code is presented as examples; it contains no installation steps, script execution, network calls, or credential requests.

View source
SKILL.md:2In the instructionsOpen original file
---name: api-and-interface-designdescription: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.---
SKILL.md:8In the instructionsOpen original file
## OverviewDesign stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.

The document explicitly treats third-party API responses as untrusted and calls for validating their shape and content before using them in logic, rendering, or decisions.

View source
SKILL.md:115In the instructionsOpen original file
- Form submission handlers (user input)- External service response parsing (third-party data -- **always treat as untrusted**)- Environment variable loading (configuration)> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.

For requests with side effects such as charging, the document describes idempotency controls including atomic key claims, payload checks, and handling timeouts with unknown outcomes to reduce duplicate actions.

View source
SKILL.md:173In the instructionsOpen original file
**Claim atomically. A check followed by an act is a race:**```typescript// ✗ TOCTOU: two concurrent retries both read "not seen", both chargeif (!(await db.exists(key))) {  await chargeCard(amount);  await db.insert(key);}// ✓ let the unique constraint pick the winnertry {  await db.insert({ key, state: 'in_progress', requestHash });} catch (e) {  if (isUniqueViolation(e)) return replayOrReject(key);  throw;}const result = await chargeCard(amount);await db.update({ key, state: 'succeeded', response: result });```
SKILL.md:195In the instructionsOpen original file
**Guard the payload.** Same key with a different body is a client bug, and must fail loudly rather than serving the first response to a second request:```typescriptif (existing.requestHash !== hash(req.body)) {  return res.status(422).json({ error: 'idempotency key reused with a different payload' });}```
SKILL.md:211In the instructionsOpen original file
Never let the second caller through because the first "seems stuck". A stalled attempt whose fate is unknown is exactly when duplicating costs most.**Every call has three outcomes, not two: success, failure, and _unknown_.** A timeout tells you nothing about whether the effect applied. Record the intent *before* calling out, so a crash between the call and the response leaves evidence something must resolve later — rather than a silently retried charge.**Set retention from the longest retry chain**, not from disk cost. Keys must outlive every path that can re-deliver the same intent, including a dead-letter queue replayed a week later and any provider dispute window. A 24-hour key TTL behind a 7-day DLQ is a duplicate waiting to happen.
Start here · InstructionsSKILL.md
api-and-interface-design
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
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
Lines read
368
File checksum (to compare versions)
1a5246c4e20dcbf2adfbe362cdb915325851ae1a0721986bf4df00ca0a16df08