security-best-practices

Fail

Audited by Runlayer on Feb 21, 2026

Risk Level: HIGH
Scan Summary
Max Score
93%
Files
13
Flagged
12
Chunks
60
Flagged Files (12)
references/javascript-typescript-nextjs-web-server-security.mdHIGH
92.6%

Malicious tool definition detected

Deployment entrypoints and environment (Dockerfiles, `package.json` scripts, hosting config). 2. Next.js config (`next.config.*`), Proxy/Middleware, routing patterns.

* `NEXT_PUBLIC_API_KEY`, `NEXT_PUBLIC_SECRET`, `NEXT_PUBLIC_DATABASE_URL`, etc. * Rendering `process.env` values into HTML or returning them from API routes. Detection hints: * Scan git history and repo files for `.env` content, `DB_PASS=`, `API_KEY=`, `SECRET=`. * Grep for `NEXT_PUBLIC_` and review any sensitive-looking names. * Search for `process.env` usage in Client Components (`"use client"`) and shared modules.

Tool: references/javascript-typescript-nextjs-web-server-security.md [3/6] Description: IMPORTANT NOTE: If cookies are not being used for auth (ie auth is via Authentication header or other passed token), then there is no CSRF risk. Required: * MUST protect every state-changing endpoint that relies on cookies for auth (POST/PUT/PATCH/DELETE). * For **Server Actions**, Next.js performs an Origin/Host comparison to help prevent CSRF; do not disable or weaken it. ([Next.js][5]) * If Server Actions

Tool: references/javascript-typescript-nextjs-web-server-security.md [4/6] Description: High Required: * MUST rely on React’s default escaping; MUST NOT insert untrusted HTML into the DOM without sanitization. * MUST treat these as high-risk sinks: * `dangerouslySetInnerHTML` * rendering user-controlled strings into `<script>` tags or event handler attributes * MUST avoid serving uploaded HTML as active HTML (serve as attachment or sanitize/transform). Insecure patterns: * `<div dangerouslySetIn

--- ### NEXT-HOST-001: Host/Origin-derived URL construction MUST be allowlisted Severity: Medium Required: * MUST NOT generate security-sensitive absolute URLs (password reset links, OAuth callback URLs, email verification links) directly from unvalidated `Host` headers.

references/javascript-typescript-react-web-frontend-security.mdHIGH
91.9%

Malicious tool definition detected

Security headers posture (CSP, clickjacking, nosniff, referrer policy) in app or at the edge. ([OWASP Cheat Sheet Series][2]) --- ## 2) Definitions and review guidance ### 2.1 Untrusted input (treat as attacker-controlled unless proven otherwise) Examples include: * URL-derived data: `window.location`, query params, hash fragments, route params. * Any data from browser storage: `localStorage`, `sessionStorage`, `IndexedDB` (including data previously written by the app—because XSS or extensions c

Tool: references/javascript-typescript-react-web-frontend-security.md [2/6] Description: If rendering any user-provided HTML/markdown/rich text: * MUST sanitize before insertion and avoid raw DOM sinks. ([OWASP Cheat Sheet Series][9]) * If using service workers / PWA: * MUST serve over HTTPS and implement a safe caching/update strategy (service workers are powerful request/response proxies). ([MDN Web Docs][10]) --- ## 4) Rules (generation + audit) Each rule contains: required practice, insecure

Tool: references/javascript-typescript-react-web-frontend-security.md [3/6] Description: be attacker-controlled if it comes from users or CMS. * MUST ensure raw HTML is not rendered unless sanitized. * SHOULD prefer markdown renderers that: * Do not allow raw HTML by default, or * Can be configured to disallow raw HTML, or * Sanitize HTML output before rendering. Insecure patterns: * Markdown rendering with “raw HTML passthrough” enabled (e.g., options/plugins that allow HTML).

Fix: * Add CSRF token flow: * Fetch token from a safe endpoint and attach to state-changing requests. * Validate server-side. * Keep SameSite cookies and Origin/Referer validation as defense-in-depth.

Tool: references/javascript-typescript-react-web-frontend-security.md [5/6] Description: at the edge. * Keep CSP realistic and iterative (report-only → enforce).

Tool: references/javascript-typescript-react-web-frontend-security.md [6/6] Description: `https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity` ([MDN Web Docs][7]) * Clickjacking defenses overview — `https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking` ([MDN Web Docs][8]) * Using Service Workers (HTTPS requirement; proxy-like behavior) — `https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers` ([MDN Web Docs][10]) *

references/golang-general-backend-security.mdHIGH
90.7%

Malicious tool definition detected

Tool: references/golang-general-backend-security.md [1/6] Description: # Go (Golang) Security Spec (Go 1.25.x, Standard Library, net/http) This document is designed as a **security spec** that supports: 1) **Secure-by-default code generation** for new Go code. 2) **Security review / vulnerability hunting** in existing Go code (passive “notice issues while working” and active “scan the repo and report findings”).

Tool: references/golang-general-backend-security.md [4/6] Description: NOT call `template.Parse` / `template.ParseFiles` / `template.New(...).Parse(...)` on template text influenced by untrusted input. - MUST treat “user-defined templates” as a special high-risk design: - MUST use heavy sandboxing and strict allowlists - MUST isolate execution (process/container boundary) if truly required Insecure patterns: - `tmpl := template.Must(template.New("x").Parse(r.FormValue("tmpl")))` - Reading templa

references/javascript-express-web-server-security.mdHIGH
85.8%

Malicious tool definition detected

Tool: references/javascript-express-web-server-security.md [1/7] Description: # Express (Node.js) Web Security Spec (Express 5.x / 4.19.2+, Node.js LTS) This document is designed as a **security spec** that supports: 1. **Secure-by-default code generation** for new Express apps and routes. 2.

Fix: * Implement strict origin allowlist and ensure credentialed requests only for intended origins. * Consider splitting CORS config per route group rather than global. Notes: * OWASP HTTP header guidance covers security implications of response headers, including those that affect browser behavior; use it as a reference when reviewing header posture. ([OWASP Cheat Sheet Series][10]) --- ### EXPRESS-PROXY-001: Reverse proxy trust (`trust proxy`) must be configured correctly Severity: Medium (Hi

Notes: * OWASP Node.js cheat sheet explicitly highlights that Express query parsing can produce strings, arrays, or objects and recommends preventing HTTP Parameter Pollution. ([OWASP Cheat Sheet Series][8]) --- ### EXPRESS-XSS-001: Prevent reflected/stored XSS in HTML responses and templating Severity: High Required: * MUST escape untrusted content in HTML output (templates should auto-escape by default; do not bypass). * MUST NOT inject untrusted strings into HTML without escaping/sanitization

Tool: references/javascript-express-web-server-security.md [6/7] Description: rate-limit by: 1. consecutive failed attempts per username+IP 2. failed attempts per IP over a time window Insecure patterns: * Unlimited login attempts.

Tool: references/javascript-express-web-server-security.md [7/7]

references/python-django-web-server-security.mdHIGH
82.2%

Malicious tool definition detected

Tool: references/python-django-web-server-security.md [1/5] Description: # Django (Python) Web Security Spec (Django 6.0.x, Python 3.x) This document is designed as a **security spec** that supports: 1. **Secure-by-default code generation** for new Django code. 2.

* Add HSTS carefully (start with low value, validate, then increase). Django warns misconfig can break your site for the HSTS duration. ([Django Project][3]) --- ### DJANGO-PROXY-001: Reverse proxy trust must be configured correctly (`SECURE_PROXY_SSL_HEADER`) Severity: Medium (when behind a TLS proxy) Required: * If behind a reverse proxy that terminates TLS, MUST configure Django so `request.is_secure()` reflects the *external* scheme, otherwise CSRF and other logic can break. Django documents

Tool: references/python-django-web-server-security.md [4/5] Description: attacker-influenced content. * SHOULD use strict allowlists for variable components. * SHOULD prefer pure-Python libraries instead of shelling out. Insecure patterns: * `os.system(request.GET["cmd"])` * `subprocess.run(f"convert {path}", shell=True)` where `path` is user-controlled.

Tool: references/python-django-web-server-security.md [5/5] Description: * SHOULD configure `AUTH_PASSWORD_VALIDATORS` (default is empty) for production password policy. ([Django Project][3]) Insecure patterns: * Custom password storage or hashing.

references/javascript-general-web-frontend-security.mdHIGH
81.5%

Malicious tool definition detected

Tool: references/javascript-general-web-frontend-security.md [1/5] Description: # Frontend JavaScript/TypeScript Web Security Spec (Vanilla Browser JS/TS, Modern Browsers) This document is designed as a **security spec** that supports: 1. **Secure-by-default code generation** for new frontend JavaScript/TypeScript (no specific framework assumed). 2.

([OWASP Cheat Sheet Series][2]) * If HTML insertion is truly required, SHOULD sanitize with a well-reviewed HTML sanitizer and strongly consider enforcing Trusted Types to confine usage to audited code paths. ([MDN Web Docs][11]) Insecure patterns: * `el.innerHTML = userInput` * `el.insertAdjacentHTML('beforeend', userInput)` * `el.outerHTML = userInput` Detection hints: * Search for: `.innerHTML`, `.outerHTML`, `insertAdjacentHTML(`. * Trace the origin of inserted string: URL params/hash, postM

Please perform extra analysis to determine if the url is fully attacker controlled. If not fully attacker controlled, then this is informational at best. * Some apps intentionally support external redirects (SSO, payment flows). Those MUST be allowlisted and documented.

Tool: references/javascript-general-web-frontend-security.md [4/5] Description: DOM injection sinks; it is not a universal sandbox.) ([W3C][15]) Detection hints: * Search for CSP directives: `require-trusted-types-for` and `trusted-types`. * Search code for `trustedTypes.createPolicy(` and inspect policy implementations. ([MDN Web Docs][11]) Fix: * Add a small set of well-reviewed policies (e.g., `createHTML` that sanitizes).

references/python-flask-web-server-security.mdHIGH
78.6%

Malicious tool definition detected

- `SESSION_COOKIE_HTTPONLY=True` - `SESSION_COOKIE_SAMESITE='Lax'` (or `'Strict'` if compatible) - `TRUSTED_HOSTS` set in production - Security headers set (CSP, etc.) either in app or at the edge -------------------------------------------------------------------- ## 4) Rules (generation + audit) Each rule contains: required practice, insecure patterns, detection hints, and remediation. ### FLASK-DEPLOY-001: Do not use Flask’s development server in production Severity: High (if production) Requ

Detection hints: - Search for `PERMANENT_SESSION_LIFETIME`, `session.permanent`, `session[...] =`. - Identify whether server-side session storage is used; if not, assume default cookie sessions. Fix: - Set appropriate lifetimes. - Clear/rotate session on login. - Store sensitive data server-side; store only identifiers in the session cookie.

Detection hints: - Search for `ProxyFix`. - Search for usage of `request.remote_addr`, `request.scheme`, `request.host` in security-sensitive logic. Fix: - Configure `ProxyFix` (or platform-specific settings) with correct hop counts. - Keep `TRUSTED_HOSTS` in place even behind proxies. --- ### FLASK-PATH-001: Prevent path traversal and unsafe file serving Severity: High Required: - MUST NOT pass user-controlled file paths to `send_file` or to direct file I/O.

Tool: references/python-flask-web-server-security.md [4/5] Description: - Check where files are stored and how they are served. Fix: - Implement allowlist validation + safe storage + safe serving. - Add scanning / quarantine if applicable.

Tool: references/python-flask-web-server-security.md [5/5]

references/javascript-jquery-web-frontend-security.mdHIGH
78.3%

Malicious tool definition detected

Tool: references/javascript-jquery-web-frontend-security.md [1/5] Description: # jQuery Frontend Security Spec (jQuery 4.0.x, modern browsers) This document is designed as a **security spec** that supports: 1. **Secure-by-default code generation** for new jQuery-based frontend code. 2.

([blog.jquery.com][7]) ### 3.4 Security headers and cookie posture (defense in depth; SHOULD) Even though these are typically set server-side, they materially reduce the blast radius of jQuery-related mistakes. However if the context is only the frontend web application, these cannot be acted on. * SHOULD set common security headers (CSP, `X-Content-Type-Options: nosniff`, clickjacking protection via `frame-ancestors` / `X-Frame-Options`, `Referrer-Policy`).

* Identify how the server expects CSRF validation (meta tag, cookie-to-header double submit, synchronizer token, etc.). Fix: * Add CSRF token inclusion in a centralized place, e.g., `$.ajaxSetup({ headers: { "X-CSRF-Token": token } })`, and ensure server verifies. * Follow OWASP CSRF guidance for token properties and validation.

references/javascript-typescript-vue-web-frontend-security.mdHIGH
78.3%

Tool passed security scan

Malicious tool definition detected

* Hard-coded API keys, private tokens, service credentials, signing keys in JS/TS. Detection hints: * Search: `VITE_`, `import.meta.env`, `.env`, `.env.production`, `.env.*.local`. * Grep for `API_KEY`, `SECRET`, `TOKEN`, `PRIVATE_KEY`, `BEGIN`, `sk-`, `AKIA`, etc. Fix: * Move secrets to backend/edge functions.

Tool: references/javascript-typescript-vue-web-frontend-security.md [3/4] Description: user customization is needed. ([Vue.js][1]) * SHOULD isolate “user can control layout/CSS” features inside sandboxed iframes. Insecure patterns: * `:style="userProvidedStyles"` where styles are attacker-controlled. * Rendering user-provided `<style>` content (even if Vue blocks some patterns, don’t try to work around it).

Tool: references/javascript-typescript-vue-web-frontend-security.md [4/4] Description: of `innerHTML`/`v-html` without sanitization or CSP hardening. Detection hints: * Search: `v-html`, `innerHTML`, `insertAdjacentHTML`.

references/python-fastapi-web-server-security.mdHIGH
78.3%

Malicious tool definition detected

Tool: references/python-fastapi-web-server-security.md [1/6] Description: # FastAPI (Python) Web Security Spec (FastAPI 0.128.x, Python 3.x) ([PyPI][1]) This document is designed as a **security spec** that supports: 1. **Secure-by-default code generation** for new FastAPI code. 2.

Tool: references/python-fastapi-web-server-security.md [2/6] Description: Required: * MUST NOT enable debug tracebacks in production (FastAPI/Starlette debug mode can expose sensitive internals and make some exploit chains easier). ([PyPI][5]) * MUST treat any configuration that returns detailed stack traces to clients as sensitive. Insecure patterns: * `app = FastAPI(debug=True)` (or Starlette `debug=True`), or equivalent environment toggles enabling debug in production. ([PyPI][5]) * Server/lo

Fix: * Set secure cookie attributes; prefer short lifetimes for high-privilege sessions. ([OWASP Cheat Sheet Series][8]) --- ### FASTAPI-SESS-002: Do not store sensitive secrets in signed session cookies Severity: High Required: * MUST assume cookie-based session data is readable by the client (signed ≠ encrypted); do not store secrets/PII unless encrypted server-side. * Store only opaque identifiers (e.g., session ID) or non-sensitive state in the cookie; store sensitive session state server-si

Tool: references/python-fastapi-web-server-security.md [5/6] Description: * Passing user strings into `bash -c`, `sh -c`, PowerShell, etc. Detection hints: * Search for `os.system`, `subprocess`, `Popen`, `shell=True`.

Tool: references/python-fastapi-web-server-security.md [6/6]

SKILL.mdMEDIUM
40.4%

Tool passed security scan

LICENSE.txtLOW
39.4%

Tool passed security scan

Passed Files (1)Click to expand
agents/openai.yamlOK
14.5%

Tool passed security scan

Audit Metadata
Max File Score
93%
Classification
UNKNOWN_SERVER
Files Scanned
13
Files Flagged
12
Chunks Analyzed
60
Analyzed
Feb 21, 2026, 11:32 PM
Security Audit — runlayer — security-best-practices