FastAPI Production Patterns

• Outcome: Pass
• Latest audit: Sep 11, 2026 · 4:59 AM UTC
• Version: 1.0.0

Overview

This is a documentation-only FastAPI skill with some insecure production examples users should harden before copying.

Install only as general FastAPI reference material. Before using its snippets in real services, replace the JWT secret with secure secret management, avoid returning raw exception details from health endpoints, pin and review dependencies, and check any outbound HTTP examples for sensitive data exposure.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:180
• Finding: Unpinned Dependency Installation Creates Supply-Chain Risk<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:180`, `SKILL.md:243-244` **Vulnerability Type**: Unpinned and mutable third-party dependencies **Risk Level**: Medium ### Vulnerable Code ```dockerfile RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt ``` ```text - `pip install fastapi[all]` - FastAPI with all optional dependencies - `pip install pytest anyio httpx` - async testing stack ``` ### Technical Analysis The Skill recommends installing Python packages without fixed versions or cryptographic hashes. Package resolution can therefore change between installations, making builds non-reproducible and allowing newly released or compromised direct and transitive dependencies to enter the environment without review. The `--upgrade` option further increases this exposure by directing `pip` to replace already installed packages with newer compatible versions. The Skill does not recommend a lock file, hash verification, dependency review, or a trusted package mirror. This is guidance rather than directly executed code, and there is no evidence that the currently named packages are malicious. The vulnerability arises when users copy these production patterns into build or deployment workflows. ### Attack Path 1. A developer follows the Skill and installs the dependencies without pinned versions or hashes. 2. The package resolver queries the configured Python package index during a later build. 3. A compromised, malicious, dependency-confused, or unexpectedly incompatible package version satisfies the mutable dependency constraints. 4. The package is downloaded and installed without integrity validation against a reviewed lock file. 5. Malicious installation hooks or imported package code execute with the privileges of the build process or application container. ### Impact Assessment Successful exploitation could execute arbitrary code within the dependency installation or application runtime context. The attainable privileg ...[truncated 459 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin all direct dependencies to reviewed versions. - Generate and commit a lock file that includes transitive dependencies. - Require cryptographic hashes during installation, such as with `pip install --require-hashes`. - Remove uncontrolled `--upgrade` behavior from production image builds. - Use an approved internal package mirror or explicitly trusted package index. - Scan dependencies and container images for known vulnerabilities. - Regularly update dependencies through a controlled review and testing process. - Replace the examples with hardened commands, such as installation from a hash-locked requirements file: ```dockerfile RUN pip install --no-cache-dir --require-hashes -r requirements.lock ``` ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:195
• Finding: Readiness Endpoint Exposes Internal Exception Details<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:195-203` **Vulnerability Type**: Information disclosure through raw exception messages **Risk Level**: Medium ### Vulnerable Code ```python @app.get("/ready") async def readiness_check(): """Readiness: can it handle traffic?""" try: await database.execute("SELECT 1") return {"status": "ready", "database": "ok"} except Exception as e: raise HTTPException(status_code=503, detail=str(e)) ``` ### Technical Analysis The readiness endpoint converts the complete exception message into an HTTP response by using `detail=str(e)`. Database and infrastructure exceptions commonly contain internal hostnames, ports, driver names, database identifiers, query details, schema information, file paths, or configuration values. Because the Skill presents this as a production health-check pattern, copying it could expose implementation details to any client able to reach the readiness endpoint. The broad `except Exception` handler also makes disclosure possible for an extensive range of unexpected failures. The response does not intentionally transmit application secrets, and the generic HTTP client examples elsewhere in the file do not send sensitive data. The confirmed issue is the avoidable disclosure of runtime error details in the readiness response. ### Attack Path 1. An application deploys the documented readiness endpoint. 2. An attacker or unauthorized network client accesses `/ready`. 3. The attacker waits for or induces a database failure, such as connection refusal, authentication failure, timeout, or malformed configuration. 4. The database library raises an exception containing internal diagnostic details. 5. The endpoint converts the exception to text and returns it in the HTTP 503 response. 6. The attacker uses the disclosed infrastructure information for reconnaissance and follow-on attacks. ### Impact Assessment This issue does not directly provide code exec ...[truncated 500 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Return a fixed, non-sensitive error response to clients. - Record full exception details only in protected server-side logs. - Restrict readiness endpoints to trusted orchestration or internal management networks. - Catch expected database exceptions rather than using an unnecessarily broad handler where practical. - Ensure logs are access-controlled and redact credentials, connection strings, tokens, and other sensitive values. - Add tests confirming that readiness responses never contain exception text or infrastructure details. A safer pattern is: ```python @app.get("/ready") async def readiness_check(): try: await database.execute("SELECT 1") return {"status": "ready", "database": "ok"} except Exception: logger.exception("Readiness database check failed") raise HTTPException( status_code=503, detail="Service unavailable", ) ``` ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

return users

# Use def for: psycopg2, pymongo, requests (blocking libs)
# FastAPI automatically runs def endpoints in a threadpool
@app.get('/users/sync')
def get_users_sync():
    return sync_db.query('SELECT * FROM users')

• Confidence: 80% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The JWT example is presented as a production authentication pattern but hard-codes `SECRET_KEY = "your-secret-key"`, which can normalize insecure secret handling and lead users to deploy weak or default keys. In an auth context, a predictable or copied secret can allow token forgery and authentication bypass if reused in real deployments.

Missing User Warnings

Low

• Confidence: 83% confidence
• Finding: This markdown skill teaches OAuth2/JWT handling and later shows outbound HTTP requests, but the document does not warn users about protecting secret keys, avoiding hardcoded credentials, or the privacy implications of sending data to external services. Under the markdown-specific warning rule, examples that affect privacy or system integrity should include some disclosure or cautionary note.

Static analysis

No suspicious patterns detected.