@frontmcp/skills 1.7.0 → 1.7.2

package/catalog/frontmcp-config/examples/configure-http/cors-restricted-origins.md

@@ -5,7 +5,7 @@ level: basic
 description: 'Configure CORS to allow only specific frontend origins with credentials.'
 tags: [config, browser, http, cors, restricted, origins]
 features:
-  - 'Restricting CORS to explicit origins instead of the permissive default'
+  - 'Naming the origins a browser may read from — omitting `cors` sends no headers at all'
   - 'Enabling `credentials: true` with specific origins (required -- browsers reject `*` with credentials)'
   - 'Setting `maxAge` to reduce preflight request overhead'
   - 'Reading port from an environment variable with a fallback'
@@ -41,7 +41,7 @@ class Server {}
 
 ## What This Demonstrates
 
-- Restricting CORS to explicit origins instead of the permissive default
+- Naming the origins a browser may read from — omitting `cors` sends no headers at all
 - Enabling `credentials: true` with specific origins (required -- browsers reject `*` with credentials)
 - Setting `maxAge` to reduce preflight request overhead
 - Reading port from an environment variable with a fallback

package/catalog/frontmcp-config/references/configure-auth-modes.md

@@ -67,7 +67,7 @@ Local mode also accepts `allowDefaultPublic` (default `false` — set `true` to
 
 > **Public origin (security):** pin `FRONTMCP_PUBLIC_URL` in production. The issuer / resource / OAuth-discovery URLs and the transparent expected audience derive from it rather than from request headers; `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored unless `FRONTMCP_TRUST_PROXY=1` (a trusted proxy that strips client-supplied forwarded headers).
 
-**Progressive / incremental authorization** (opt-in via `incrementalAuth`): when enabled, the minted token carries an `authorized_apps` claim and a `tools/call` for an app NOT in that claim resolves to a `CallToolResult` with `isError: true` and `_meta.code === 'AUTHORIZATION_REQUIRED'` (fields: `authorization_required: true`, `app`, `tool`, `auth_url`, `required_scopes`, `session_mode`, `supports_incremental`). The client declares the initial grant on `/oauth/authorize?…&apps=crm` (omit `apps` to grant all apps) and expands it later via an incremental authorize `…&mode=incremental&app=slack&apps=crm` — the new token's claim is the **union** of the prior apps plus the target (the user identity and already-granted apps are preserved; upstream tokens stay server-side). Without an `incrementalAuth` block, no claim is minted and there is **no** app-level gating (allow-all preserved). `consent` (tool-level) and `incrementalAuth` (app-level) are independent.
+**Progressive / incremental authorization** (opt-in via `incrementalAuth`): when enabled, the minted token carries an `authorized_apps` claim and a `tools/call` for an app NOT in that claim resolves to a `CallToolResult` with `isError: true` and `_meta.code === 'AUTHORIZATION_REQUIRED'` (fields: `authorization_required: true`, `app`, `tool`, `auth_url`, `required_scopes`, `session_mode`, `supports_incremental`). The client declares the initial grant on `/oauth/authorize?…&apps=crm` (omit `apps` to grant all apps) and expands it later by **following the `auth_url` from the failed call** — that URL carries a framework-signed, single-use `ticket` naming the target app and the prior grant, and the new token's claim is the **union** of the prior apps plus the target (the user identity and already-granted apps are preserved; upstream tokens stay server-side). Do NOT hand-assemble `…&mode=incremental&app=slack`: since 1.7.2 (GHSA-2c4g-9c8x-6m8g) an authorize without a valid ticket is an ordinary login and runs the full credential gate, and `/oauth/callback` ignores an `incremental=true` parameter entirely. Without an `incrementalAuth` block, no claim is minted and there is **no** app-level gating (allow-all preserved). `consent` (tool-level) and `incrementalAuth` (app-level) are independent.
 
 To collect and verify your own credentials, add a declarative `login` (custom page fields / title / subject strategy) and an `authenticate(input, ctx)` verifier that returns `{ ok: true, sub?, claims? }` (custom claims are embedded in the token; reserved claims are stripped) or `{ ok: false, message }` (re-renders the login page; no code issued). Both are optional and default to the built-in email login. See `configure-auth.md` for a full example.
 

package/catalog/frontmcp-config/references/configure-http.md

@@ -33,7 +33,9 @@ Configure the HTTP server — port, CORS policy, unix sockets, entry path prefix
 - Only need rate limiting or IP filtering without changing HTTP binding -- use `configure-throttle`
 - Need to configure TLS/HTTPS termination -- handle at the reverse proxy or load balancer level, not in FrontMCP
 
-> **Decision:** Use this skill when you need to customize how the HTTP listener binds (port, socket, prefix) or how it handles CORS; skip if the default port 3000 with permissive CORS is sufficient.
+> **Decision:** Use this skill when you need to customize how the HTTP listener binds (port, socket, prefix, network interface) or how it handles CORS; skip if the defaults are sufficient — port 3000, bound to loopback, sending no CORS headers.
+
+> **Changed in v1.7.0.** The server now binds `127.0.0.1` (was `0.0.0.0`) and omitting `cors` now sends no CORS headers (was `{ origin: true }`). Reaching the server from another host or another origin is an explicit opt-in — see [Network Binding](#network-binding) and [CORS Configuration](#cors-configuration).
 
 ## HttpOptionsInput
 
@@ -46,7 +48,7 @@ Configure the HTTP server — port, CORS policy, unix sockets, entry path prefix
     entryPath: '', // default: '' (root)
     socketPath: undefined, // unix socket path (overrides port)
     cors: {
-      // default: permissive (all origins)
+      // default: undefined — no CORS headers at all
       origin: ['https://myapp.com'],
       credentials: true,
       maxAge: 86400,
@@ -87,18 +89,108 @@ http: {
 }
 ```
 
+## Network Binding
+
+The server binds `127.0.0.1` unless told otherwise — a server that says nothing about security is
+local-only. The effective address is resolved in this order, first match wins:
+
+1. `http.security.bindAddress` — `'loopback'`, `'all'`, or a literal address
+2. The `FRONTMCP_BIND_ADDRESS` environment variable — same three forms
+3. Strict mode (`http.security.strict`) — `0.0.0.0` when distributed, `127.0.0.1` otherwise
+4. A distributed build (`FRONTMCP_DEPLOYMENT_MODE=distributed`) — `0.0.0.0`
+5. The default — `127.0.0.1`
+
+```typescript
+http: {
+  security: {
+    bindAddress: 'all',  // 0.0.0.0 — reachable from other hosts
+  },
+}
+```
+
+In a container, prefer the environment variable: a Dockerfile cannot reach into the server's
+TypeScript config, and the env var needs no rebuild.
+
+```dockerfile
+ENV FRONTMCP_BIND_ADDRESS=all
+EXPOSE 3000
+```
+
+## DNS Rebinding Protection
+
+**On by default since v1.7.2** (BC-035, GHSA-mc9g-v2cp-vfff). The server validates `Host`,
+`X-Forwarded-Host` and `Origin` before routing and before reading the body; a request naming a host
+this server does not answer to gets `403`. This covers the MCP endpoint, the OAuth routes, the SSE
+transport and any custom route.
+
+Binding loopback does **not** protect against this: a DNS rebinding attack points an
+attacker-controlled domain at `127.0.0.1`, so loopback is the destination. CORS does not either —
+after the rebind the browser genuinely considers the request same-origin. Validating `Host` is the
+server-side defence.
+
+With no `allowedHosts` configured, the list is derived from what the process listens on: `localhost`,
+`127.0.0.1` and `[::1]`, each with and without the bound port, plus a specific bound NIC address.
+Matching is case-insensitive and treats `host` and `host:80`/`host:443` as equal.
+
+**Deployments behind a proxy need one line of config.** A routable bind (`0.0.0.0`, `::`, a specific
+NIC) is reached under a hostname the process cannot know, so a derived list is not enforced there —
+FrontMCP logs a warning and leaves host checking off rather than 403-ing a proxied deployment on a
+patch upgrade. Name the public host to turn it on:
+
+```typescript
+http: {
+  security: {
+    dnsRebindingProtection: {
+      allowedHosts: ['api.example.com', 'api.example.com:8443'],
+      allowedOrigins: ['https://app.example.com'],
+    },
+  },
+}
+```
+
+Or via the environment, which pairs with `FRONTMCP_BIND_ADDRESS` in a container:
+
+```dockerfile
+ENV FRONTMCP_BIND_ADDRESS=all
+ENV FRONTMCP_ALLOWED_HOSTS=api.example.com,api.example.com:8443
+```
+
+To turn it off entirely: `dnsRebindingProtection: { enabled: false }`.
+
+A request with **no** `Origin` header is allowed through — non-browser clients never send one, and a
+rebound page always does. Rejecting the absent case breaks every CLI client and adds nothing.
+
 ## CORS Configuration
 
-### Permissive (Default)
+### No CORS Headers (Default)
 
-When `cors` is not specified, the server allows all origins without credentials:
+When `cors` is not specified, the server sends **no CORS headers**. A cross-origin request still
+reaches the server and is served normally — the browser simply refuses to let the calling page read
+the response. Non-browser clients are unaffected: CORS is a browser rule, **not server-side access
+control**. If you need to keep callers out, use authentication.
+
+`cors: {}` and `cors: { origin: false }` behave identically to omitting the option — the middleware
+is installed only when `origin` is set to something other than `false`.
 
 ```typescript
-// All origins allowed (default behavior)
+// No CORS headers (default behavior)
 http: {
 }
 ```
 
+### Allow Any Origin
+
+The pre-v1.7.0 default. Reflects whatever `Origin` the request carries, so any page a user visits
+can read this server's responses — never use it in production.
+
+```typescript
+http: {
+  cors: {
+    origin: true,
+  },
+}
+```
+
 ### Restrict to Specific Origins
 
 ```typescript
@@ -139,11 +231,11 @@ http: {
 
 ### CORS Fields
 
-| Field         | Type                                        | Default      | Description                        |
-| ------------- | ------------------------------------------- | ------------ | ---------------------------------- |
-| `origin`      | `boolean \| string \| string[] \| function` | `true` (all) | Allowed origins                    |
-| `credentials` | `boolean`                                   | `false`      | Allow cookies/auth headers         |
-| `maxAge`      | `number`                                    | —            | Preflight cache duration (seconds) |
+| Field         | Type                                        | Default | Description                                                                        |
+| ------------- | ------------------------------------------- | ------- | ---------------------------------------------------------------------------------- |
+| `origin`      | `boolean \| string \| string[] \| function` | none    | Allowed origins. No default — omitting it (or `false`) installs no CORS middleware |
+| `credentials` | `boolean`                                   | `false` | Allow cookies/auth headers                                                         |
+| `maxAge`      | `number`                                    | —       | Preflight cache duration (seconds)                                                 |
 
 ## Request Body Limits
 
@@ -345,13 +437,13 @@ curl --unix-socket /tmp/my-mcp-server.sock http://localhost/
 
 ## Common Patterns
 
-| Pattern               | Correct                                                      | Incorrect                                    | Why                                                                                                               |
-| --------------------- | ------------------------------------------------------------ | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
-| Port from environment | `port: Number(process.env.PORT) \|\| 3000`                   | `port: process.env.PORT`                     | The `port` field expects a number; passing a string causes a silent bind failure                                  |
-| CORS with credentials | `cors: { origin: ['https://myapp.com'], credentials: true }` | `cors: { origin: true, credentials: true }`  | Browsers reject `Access-Control-Allow-Origin: *` when credentials are enabled; you must list explicit origins     |
-| Unix socket mode      | `socketPath: '/tmp/my-mcp.sock'` with no `port` field        | Setting both `socketPath` and `port`         | When `socketPath` is set, `port` is silently ignored which can cause confusion during debugging                   |
-| Entry path prefix     | `entryPath: '/api/mcp'` (no trailing slash)                  | `entryPath: '/api/mcp/'` with trailing slash | Trailing slashes cause double-slash issues in route matching (e.g., `/api/mcp//sse`)                              |
-| Disabling CORS        | `cors: false`                                                | Omitting the `cors` field entirely           | Omitting `cors` applies permissive defaults (all origins allowed); set `false` explicitly to send no CORS headers |
+| Pattern               | Correct                                                      | Incorrect                                    | Why                                                                                                                            |
+| --------------------- | ------------------------------------------------------------ | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| Port from environment | `port: Number(process.env.PORT) \|\| 3000`                   | `port: process.env.PORT`                     | The `port` field expects a number; passing a string causes a silent bind failure                                               |
+| CORS with credentials | `cors: { origin: ['https://myapp.com'], credentials: true }` | `cors: { origin: true, credentials: true }`  | Browsers reject `Access-Control-Allow-Origin: *` when credentials are enabled; you must list explicit origins                  |
+| Unix socket mode      | `socketPath: '/tmp/my-mcp.sock'` with no `port` field        | Setting both `socketPath` and `port`         | When `socketPath` is set, `port` is silently ignored which can cause confusion during debugging                                |
+| Entry path prefix     | `entryPath: '/api/mcp'` (no trailing slash)                  | `entryPath: '/api/mcp/'` with trailing slash | Trailing slashes cause double-slash issues in route matching (e.g., `/api/mcp//sse`)                                           |
+| Allowing cross-origin | `cors: { origin: ['https://myapp.com'] }`                    | Omitting the `cors` field entirely           | Omitting `cors` (like `cors: false`) sends no CORS headers at all; a browser on another origin needs an explicit `origin` list |
 
 ## Verification Checklist
 
@@ -362,8 +454,14 @@ curl --unix-socket /tmp/my-mcp-server.sock http://localhost/
 - [ ] If `socketPath` is set, `port` is removed or commented out to avoid confusion
 - [ ] `entryPath` does not have a trailing slash
 
+### Network Binding
+
+- [ ] If the server must be reachable from another host, `security.bindAddress` or `FRONTMCP_BIND_ADDRESS` is set — the default is loopback-only
+- [ ] Containers set `FRONTMCP_BIND_ADDRESS=all` so the published port reaches the process
+
 ### CORS
 
+- [ ] `cors` is set only if a browser on another origin needs access — omitting it sends no headers
 - [ ] If `credentials: true`, `origin` lists explicit allowed origins (not `true` or `*`)
 - [ ] `maxAge` is set to a reasonable value for production (e.g., `86400` for 24 hours)
 - [ ] Dynamic origin function handles `undefined` origin (non-browser requests)
@@ -390,7 +488,7 @@ curl --unix-socket /tmp/my-mcp-server.sock http://localhost/
 | CORS errors in the browser console                    | Origin not included in the `cors.origin` list or `credentials: true` with wildcard origin                            | Add the frontend origin to the `origin` array and ensure credentials and origin settings are compatible  |
 | Unix socket file not created                          | Missing write permissions on the target directory or stale socket file from a previous run                           | Check directory permissions and remove the stale `.sock` file before restarting                          |
 | Routes return 404 after setting `entryPath`           | Client is still requesting the root path without the prefix                                                          | Update client base URL to include the entry path (e.g., `http://localhost:3000/api/mcp`)                 |
-| Server binds but external clients cannot connect      | Server bound to `localhost` or `127.0.0.1` inside a container                                                        | Set `host: '0.0.0.0'` or use Docker port mapping to expose the container port                            |
+| Server binds but external clients cannot connect      | The default bind address is `127.0.0.1`, which a published container port cannot reach                               | Set `FRONTMCP_BIND_ADDRESS=all` in the container (or `http.security.bindAddress: 'all'` in the config)   |
 | `413 Payload Too Large` with JSON-RPC envelope        | Request body exceeded `bodyLimit` (default `'4mb'`)                                                                  | Raise `http.bodyLimit` to fit the payload, or move large blobs to a separate upload endpoint             |
 | Server throws at startup mentioning a "reserved" path | A custom `http.routes` path collides with the MCP entry path, `/oauth/*`, `/.well-known/*`, `/health`, or `/metrics` | Rename the custom route to a non-reserved path                                                           |
 | Custom route returns JSON when HTML/bytes expected    | The Express adapter defaults responses to `application/json`                                                         | Set `res.setHeader('Content-Type', ...)` (or `res.type(...)`) in the handler before sending the body     |

package/catalog/frontmcp-config/references/configure-transport.md

@@ -45,7 +45,7 @@ Configure how clients connect to your FrontMCP server — SSE, Streamable HTTP,
     distributedMode: 'auto', // boolean | 'auto'
     eventStore: {
       enabled: true,
-      provider: 'redis', // 'memory' | 'redis'
+      provider: 'redis', // 'memory' | 'redis' | 'sqlite'
       maxEvents: 10000,
       ttlMs: 300000,
     },
@@ -115,7 +115,7 @@ Enable event store so clients can resume SSE connections after disconnects:
 transport: {
   eventStore: {
     enabled: true,
-    provider: 'redis',       // 'memory' for single instance, 'redis' for distributed
+    provider: 'redis',       // 'memory' | 'redis' | 'sqlite'
     maxEvents: 10000,        // max events to store
     ttlMs: 300000,           // 5 minute TTL
     redis: { provider: 'redis', host: 'localhost' },
@@ -123,6 +123,12 @@ transport: {
 }
 ```
 
+**Auto-enabled in distributed mode.** A distributed deployment with Redis configured turns the event store on without an explicit `eventStore` block, so the notes below apply there too.
+
+**Requires 1.7.2 or later.** Before 1.7.2 (GHSA-84j6-jc92-77jm) one store instance was shared by every session with no ownership check on replay, and the upstream transport writes every session's standalone SSE stream under the constant id `_GET_stream` with sequential event numbers — so a client sending `Last-Event-ID: _GET_stream:1` was replayed other sessions' server-to-client messages (tool results, resource contents, notifications). On 1.7.1 or earlier, do not enable the event store on a multi-tenant deployment.
+
+From 1.7.2 each session gets a view over the shared store scoped to its own session id: an event id belonging to another session replays nothing.
+
 ## Target-Specific Recommendations
 
 | Target                   | Recommended Preset | Persistence | Event Store |

package/catalog/frontmcp-deployment/examples/build-for-sdk/create-flat-config.md

@@ -42,6 +42,10 @@ async function main() {
           case 'multiply':
             return { result: input.a * input.b };
           case 'divide':
+            // `z.number()` accepts 0, so guard the divisor: 1/0 is Infinity, which JSON
+            // serialises as null, and 0/0 is NaN, which the output schema rejects with an
+            // opaque error. Fail with a message the caller can act on instead.
+            if (input.b === 0) throw new Error('Cannot divide by zero');
             return { result: input.a / input.b };
         }
       }),

package/catalog/frontmcp-deployment/examples/deploy-to-node/docker-compose-with-redis.md

@@ -70,6 +70,8 @@ RUN npx frontmcp build --target node
 FROM node:24-alpine AS production
 WORKDIR /app
 ENV NODE_ENV=production
+# The server binds 127.0.0.1 by default, which a published container port cannot reach.
+ENV FRONTMCP_BIND_ADDRESS=all
 COPY --from=builder /app/dist ./dist
 COPY --from=builder /app/package.json ./
 COPY --from=builder /app/yarn.lock ./

package/catalog/frontmcp-deployment/examples/deploy-to-node/pm2-with-nginx.md

@@ -54,7 +54,8 @@ server {
 # .env
 PORT=3000
 NODE_ENV=production
-HOST=0.0.0.0
+# No FRONTMCP_BIND_ADDRESS here on purpose: the server binds 127.0.0.1 by default,
+# which is exactly right when NGINX on the same host is the only thing talking to it.
 REDIS_URL=redis://localhost:6379
 LOG_LEVEL=info
 ```

package/catalog/frontmcp-deployment/examples/deploy-to-node-dockerfile/basic-multistage-dockerfile.md

@@ -31,6 +31,8 @@ RUN yarn frontmcp build --target node
 FROM node:24-alpine AS production
 WORKDIR /app
 ENV NODE_ENV=production
+# The server binds 127.0.0.1 by default, which a published container port cannot reach.
+ENV FRONTMCP_BIND_ADDRESS=all
 ENV PORT=3000
 COPY --from=builder /app/dist ./dist
 COPY --from=builder /app/package.json ./

package/catalog/frontmcp-deployment/examples/deploy-to-node-dockerfile/secure-nonroot-dockerfile.md

@@ -50,6 +50,8 @@ USER frontmcp
 
 # Environment defaults
 ENV NODE_ENV=production
+# The server binds 127.0.0.1 by default, which a published container port cannot reach.
+ENV FRONTMCP_BIND_ADDRESS=all
 ENV PORT=3000
 
 EXPOSE 3000

package/catalog/frontmcp-deployment/references/build-for-sdk.md

@@ -69,15 +69,34 @@ const server = await create({
     tool({
       name: 'calculate',
       description: 'Perform calculation',
-      inputSchema: { expression: z.string() },
+      inputSchema: {
+        a: z.number(),
+        b: z.number(),
+        operation: z.enum(['add', 'subtract', 'multiply', 'divide']),
+      },
       outputSchema: { result: z.number() },
-    })((input) => ({ result: eval(input.expression) })),
+    })((input) => {
+      switch (input.operation) {
+        case 'add':
+          return { result: input.a + input.b };
+        case 'subtract':
+          return { result: input.a - input.b };
+        case 'multiply':
+          return { result: input.a * input.b };
+        case 'divide':
+          // `z.number()` accepts 0, so guard the divisor: 1/0 is Infinity, which JSON
+          // serialises as null, and 0/0 is NaN, which the output schema rejects with an
+          // opaque error. Fail with a message the caller can act on instead.
+          if (input.b === 0) throw new Error('Cannot divide by zero');
+          return { result: input.a / input.b };
+      }
+    }),
   ],
   cacheKey: 'my-service', // Reuse same instance on repeated calls
 });
 
 // Call tools directly
-const result = await server.callTool('calculate', { expression: '2 + 2' });
+const result = await server.callTool('calculate', { a: 2, b: 2, operation: 'add' });
 
 // List available tools
 const { tools } = await server.listTools();
@@ -86,6 +105,13 @@ const { tools } = await server.listTools();
 await server.dispose();
 ```
 
+> **Never `eval()` tool input.** A tool's arguments come from the MCP caller, or from an LLM acting
+> on caller-controlled prompts — they are untrusted by definition. `eval` on that value runs with the
+> embedding process's full authority: environment credentials, the filesystem, the network, and
+> `process.getBuiltinModule('child_process')`. Output-schema validation cannot help, because the side
+> effects happen before the result is validated. Model the operation in the schema, as above, so the
+> set of things the tool can do is fixed at design time.
+
 ### CreateConfig Fields
 
 ```typescript

package/catalog/frontmcp-deployment/references/deploy-to-node-dockerfile.md

@@ -65,6 +65,8 @@ USER frontmcp
 
 # Environment defaults
 ENV NODE_ENV=production
+# The server binds 127.0.0.1 by default, which a published container port cannot reach.
+ENV FRONTMCP_BIND_ADDRESS=all
 ENV PORT=3000
 
 EXPOSE 3000

package/catalog/frontmcp-deployment/references/deploy-to-node.md

@@ -130,7 +130,10 @@ Create a `.env` file or set variables in your deployment environment:
 # Server
 PORT=3000
 NODE_ENV=production
-HOST=0.0.0.0
+# The server binds 127.0.0.1 by default. Set this only when it must be reachable
+# from another host — a container, a VM, direct access. Behind a reverse proxy on
+# the same machine, leave it unset.
+FRONTMCP_BIND_ADDRESS=all
 
 # Redis (required for session storage in production)
 REDIS_URL=redis://localhost:6379
@@ -139,13 +142,13 @@ REDIS_URL=redis://localhost:6379
 LOG_LEVEL=info
 ```
 
-| Variable    | Description                         | Default       |
-| ----------- | ----------------------------------- | ------------- |
-| `PORT`      | HTTP port for the server            | `3000`        |
-| `NODE_ENV`  | Runtime environment                 | `development` |
-| `REDIS_URL` | Redis connection string for storage | (none)        |
-| `HOST`      | Network interface to bind           | `0.0.0.0`     |
-| `LOG_LEVEL` | Logging verbosity                   | `info`        |
+| Variable                | Description                                                        | Default                  |
+| ----------------------- | ------------------------------------------------------------------ | ------------------------ |
+| `PORT`                  | HTTP port for the server                                           | `3000`                   |
+| `NODE_ENV`              | Runtime environment                                                | `development`            |
+| `REDIS_URL`             | Redis connection string for storage                                | (none)                   |
+| `FRONTMCP_BIND_ADDRESS` | Network interface to bind: `all`, `loopback`, or a literal address | `loopback` (`127.0.0.1`) |
+| `LOG_LEVEL`             | Logging verbosity                                                  | `info`                   |
 
 ## Step 5: Health Checks
 

package/catalog/frontmcp-development/examples/create-job/job-with-permissions.md

@@ -112,6 +112,8 @@ class DataServer {}
 ## What This Demonstrates
 
 - Declarative `permissions` as an array of `{ action, roles, scopes, custom }` rules
+  (**enforced from 1.7.2 onward** — see GHSA-58v2-gpcc-jmqv; earlier versions
+  stored the rules without evaluating them)
 - Using `tags` and `labels` for categorization and filtering
 - The `job()` function builder for simple jobs that need no class
 - Full server registration with `jobs.enabled: true` and a Redis store

package/catalog/frontmcp-development/references/create-job.md

@@ -35,17 +35,17 @@ Create a class extending `JobContext<In, Out>` and implement the `execute(input:
 
 ### JobMetadata Fields
 
-| Field          | Type                     | Required | Default          | Description                                |
-| -------------- | ------------------------ | -------- | ---------------- | ------------------------------------------ |
-| `name`         | `string`                 | Yes      | --               | Unique job name                            |
-| `inputSchema`  | `ZodRawShape`            | Yes      | --               | Zod raw shape for input validation         |
-| `outputSchema` | `ZodRawShape \| ZodType` | Yes      | --               | Zod schema for output validation           |
-| `description`  | `string`                 | No       | --               | Human-readable description                 |
-| `timeout`      | `number`                 | No       | `300000` (5 min) | Maximum execution time in milliseconds     |
-| `retry`        | `RetryPolicy`            | No       | --               | Retry configuration (see below)            |
-| `tags`         | `string[]`               | No       | --               | Categorization tags                        |
-| `labels`       | `Record<string, string>` | No       | --               | Key-value labels for filtering             |
-| `permissions`  | `JobPermission[]`        | No       | --               | Array of permission rules (one per action) |
+| Field          | Type                     | Required | Default          | Description                                                                                        |
+| -------------- | ------------------------ | -------- | ---------------- | -------------------------------------------------------------------------------------------------- |
+| `name`         | `string`                 | Yes      | --               | Unique job name                                                                                    |
+| `inputSchema`  | `ZodRawShape`            | Yes      | --               | Zod raw shape for input validation                                                                 |
+| `outputSchema` | `ZodRawShape \| ZodType` | Yes      | --               | Zod schema for output validation                                                                   |
+| `description`  | `string`                 | No       | --               | Human-readable description                                                                         |
+| `timeout`      | `number`                 | No       | `300000` (5 min) | Maximum execution time in milliseconds                                                             |
+| `retry`        | `RetryPolicy`            | No       | --               | Retry configuration (see below)                                                                    |
+| `tags`         | `string[]`               | No       | --               | Categorization tags                                                                                |
+| `labels`       | `Record<string, string>` | No       | --               | Key-value labels for filtering                                                                     |
+| `permissions`  | `JobPermission[]`        | No       | --               | Array of permission rules. Multiple rules may target the same action; all matching rules must pass |
 
 ### Basic Example
 
@@ -266,13 +266,17 @@ class ImportCsvJob extends JobContext {
 
 Control who can interact with jobs using the `permissions` field. **`permissions` is an array** of rules; each rule grants access to a single `action` and lists the roles, scopes, and/or custom predicate required for that action.
 
+**Requires 1.7.2 or later.** Before 1.7.2 (GHSA-58v2-gpcc-jmqv) the `permissions` array was validated and stored but never evaluated — every job was reachable by every caller who could reach `execute_job`. On older versions do not rely on this field for access control.
+
+Semantics: no rules for an action means allow (the documented default); once any rule targets an action, **all** rules for that action must pass, and `roles`/`scopes` within a single rule are **any-of**. Enforcement happens in `JobExecutionManager`, so background runs and workflow steps are covered, and `list_jobs` hides entries the caller could not run. A denial is indistinguishable from "not found" so restricted job names cannot be enumerated.
+
 ### Permission Rule Shape
 
 ```typescript
 interface JobPermission {
   action: 'create' | 'read' | 'update' | 'delete' | 'execute' | 'list'; // singular!
-  roles?: string[]; // user must have one of these roles
-  scopes?: string[]; // token must include all of these scopes
+  roles?: string[]; // caller must have one of these roles
+  scopes?: string[]; // token must include one of these scopes
   custom?: (authInfo: Partial<Record<string, unknown>>) => boolean | Promise<boolean>;
 }
 ```
@@ -418,7 +422,7 @@ class DataApp {}
 
 ### Enabling the Jobs System
 
-**Auto-enable (issue #408):** declaring any `@App({ jobs: [...] })` (or `workflows: [...]`) is enough — the jobs subsystem comes up with in-memory stores by default and the management tools (`execute_job`, `list_jobs`, `get_job_status`, `register_job`, `remove_job`) are registered automatically so agents can invoke them. No `@FrontMcp({ jobs: { enabled: true } })` is required for the happy path.
+**Auto-enable (issue #408):** declaring any `@App({ jobs: [...] })` (or `workflows: [...]`) is enough — the jobs subsystem comes up with in-memory stores by default and the management tools (`execute_job`, `list_jobs`, `get_job_status`, `remove_job`) are registered automatically so agents can invoke them. `register_job` is added only when `jobs.allowDynamicRegistration` is `true`. No `@FrontMcp({ jobs: { enabled: true } })` is required for the happy path.
 
 **When to configure `@FrontMcp({ jobs })` explicitly:** override the in-memory default with persistent storage (Redis recommended for multi-replica HA) so job state, progress, logs, and outputs survive retries and server restarts.
 
@@ -450,17 +454,27 @@ Setting `jobs: { enabled: false }` is an explicit opt-out — declared jobs will
 
 Once jobs are registered, the SDK exposes five MCP tools (snake_case per ecosystem convention; hyphen aliases like `execute-job` keep working with a deprecation log line for one release):
 
-| Tool             | Purpose                                                                  |
-| ---------------- | ------------------------------------------------------------------------ |
-| `list_jobs`      | List registered jobs with optional `tags` / `labels` / `query` filters   |
-| `execute_job`    | Execute a registered job by name (`{ name, input?, background? }`)       |
-| `get_job_status` | Get the run state for a `runId` returned by `execute_job`                |
-| `register_job`   | Register a dynamic job at runtime (sandboxed; `hideFromDiscovery: true`) |
-| `remove_job`     | Remove a dynamic job by name (`hideFromDiscovery: true`)                 |
+| Tool             | Purpose                                                                |
+| ---------------- | ---------------------------------------------------------------------- |
+| `list_jobs`      | List registered jobs with optional `tags` / `labels` / `query` filters |
+| `execute_job`    | Execute a registered job by name (`{ name, input?, background? }`)     |
+| `get_job_status` | Get the run state for a `runId` returned by `execute_job`              |
+| `register_job`   | Register a dynamic job at runtime — **opt-in**, see below              |
+| `remove_job`     | Remove a dynamic job by name (`hideFromDiscovery: true`)               |
 
 Workflows expose a parallel set: `list_workflows`, `execute_workflow`, `get_workflow_status`, `register_workflow`, `remove_workflow`.
 
-For finer-grained control (e.g. omit `register_job` / `remove_job` in production), opt out of auto-registration by importing the tool classes manually:
+`register_job` / `register_workflow` take a **raw script string** and register it as an executable job. Since 1.7.2 they are not registered unless you opt in:
+
+```typescript
+@FrontMcp({ jobs: { enabled: true, allowDynamicRegistration: true } })
+```
+
+Leave it off unless an agent is genuinely meant to author jobs — with it on, any caller who reaches the tool list can author and run code on the server.
+
+`get_job_status` / `get_workflow_status` return only runs started by the calling subject; a run record carries the job's inputs and results, so a foreign `runId` reads as "not found".
+
+For finer-grained control, opt out of auto-registration by importing the tool classes manually:
 
 ```typescript
 import { App, ExecuteJobTool, GetJobStatusTool, ListJobsTool } from '@frontmcp/sdk';

package/catalog/frontmcp-development/references/create-workflow.md

@@ -35,16 +35,16 @@ Create a class decorated with `@Workflow`. The decorator requires `name` and `st
 
 ### WorkflowMetadata Fields
 
-| Field            | Type                               | Required    | Default           | Description                                           |
-| ---------------- | ---------------------------------- | ----------- | ----------------- | ----------------------------------------------------- |
-| `name`           | `string`                           | Yes         | --                | Unique workflow name                                  |
-| `steps`          | `WorkflowStep[]`                   | Yes (min 1) | --                | Array of step definitions                             |
-| `description`    | `string`                           | No          | --                | Human-readable description                            |
-| `trigger`        | `'manual' \| 'webhook' \| 'event'` | No          | `'manual'`        | How the workflow is initiated                         |
-| `webhook`        | `WebhookConfig`                    | No          | --                | Webhook configuration (when trigger is `'webhook'`)   |
-| `timeout`        | `number`                           | No          | `600000` (10 min) | Maximum total workflow execution time in milliseconds |
-| `maxConcurrency` | `number`                           | No          | `5`               | Maximum number of steps running in parallel           |
-| `permissions`    | `WorkflowPermission[]`             | No          | --                | Array of permission rules (one per action)            |
+| Field            | Type                               | Required    | Default           | Description                                                                                                                                                                                    |
+| ---------------- | ---------------------------------- | ----------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `name`           | `string`                           | Yes         | --                | Unique workflow name                                                                                                                                                                           |
+| `steps`          | `WorkflowStep[]`                   | Yes (min 1) | --                | Array of step definitions                                                                                                                                                                      |
+| `description`    | `string`                           | No          | --                | Human-readable description                                                                                                                                                                     |
+| `trigger`        | `'manual' \| 'webhook' \| 'event'` | No          | `'manual'`        | How the workflow is initiated                                                                                                                                                                  |
+| `webhook`        | `WebhookConfig`                    | No          | --                | Webhook configuration (when trigger is `'webhook'`)                                                                                                                                            |
+| `timeout`        | `number`                           | No          | `600000` (10 min) | Maximum total workflow execution time in milliseconds                                                                                                                                          |
+| `maxConcurrency` | `number`                           | No          | `5`               | Maximum number of steps running in parallel                                                                                                                                                    |
+| `permissions`    | `JobPermission[]`                  | No          | --                | Array of permission rules. Multiple rules may target the same action; all matching rules must pass. Same shape and semantics as job permissions; **enforced from 1.7.2** (GHSA-58v2-gpcc-jmqv) |
 
 ### WorkflowStep Fields
 

package/catalog/frontmcp-development/references/official-plugins.md

@@ -662,9 +662,23 @@ interface DashboardPluginOptionsInput {
 
 - `enabled` -- When omitted, the dashboard is automatically enabled in development (`NODE_ENV !== 'production'`) and disabled in production.
 - `basePath` -- URL path where the dashboard is served. Default: `'/dashboard'`.
-- `auth.token` -- When set, the dashboard requires `?token=<value>` as a query parameter.
+- `auth.enabled` / `auth.token` -- Gate the dashboard page on a shared secret. Present it as `Authorization: Bearer <token>` (preferred) or `?token=<value>`. `enabled: true` without a `token` is a **startup error** — the server refuses to boot rather than serve an "authenticated" dashboard with nothing to check. The token is compared in constant time and is never embedded in the served page.
 - `cdn` -- Override default CDN URLs for the dashboard UI bundle and its dependencies. Useful for air-gapped environments.
 
+### Security
+
+**Requires 1.7.2 or later.** Before 1.7.2 (GHSA-rgxj-434m-vxh3) `auth.token` was documented and validated but never checked, the operator's options never reached the middleware at all, and the dashboard's MCP scope declared `auth: { mode: 'public' }` unconditionally — so a dashboard configured with a secret still served its page, and `dashboard:graph` still returned the entire server's inventory, to anyone. On 1.7.1 or earlier, treat any server running `DashboardApp` as publicly introspectable.
+
+The dashboard's MCP scope **inherits the server's authentication**. Its introspection tools (`dashboard:graph`, `dashboard:list-tools`, `dashboard:list-resources`) reach the root scope and enumerate every app, tool, resource and prompt on the server — including names, descriptions and (on request) schemas. Two consequences:
+
+- On an authenticated server (`local`, `remote`, `transparent`, `orchestrated`), the dashboard requires the same credential as everything else.
+- On a **public** server the dashboard is public too, because the server is. `auth.token` gates the dashboard _page_, not the MCP scope or the SSE stream. If the inventory is sensitive, authenticate the server — do not rely on the dashboard token alone.
+
+Two further limitations worth knowing:
+
+- The token is accepted as `Authorization: Bearer <token>` or `?token=`. Prefer the header: a URL token lands in browser history, `Referer` headers and access logs. There is no cookie/session option yet.
+- Dashboard options are **process-wide**. Two `@FrontMcp` servers built in one process that configure the dashboard differently share the last configuration registered, including its token; the plugin logs a warning when that happens. Run one dashboard per process.
+
 ---
 
 ## Registration Pattern

package/catalog/frontmcp-production-readiness/examples/production-node-server/docker-multi-stage.md

@@ -33,6 +33,8 @@ RUN npx frontmcp build
 FROM node:24-slim AS runtime
 WORKDIR /app
 ENV NODE_ENV=production
+# The server binds 127.0.0.1 by default, which a published container port cannot reach.
+ENV FRONTMCP_BIND_ADDRESS=all
 COPY package.json yarn.lock ./
 RUN yarn install --frozen-lockfile --production && yarn cache clean
 COPY --from=builder /app/dist ./dist

package/catalog/frontmcp-production-readiness/references/common-checklist.md

@@ -29,6 +29,15 @@ These checks apply to ALL deployment targets. Run them first, then proceed to yo
 - [ ] Credentials mode is only enabled if cookies/sessions are needed
 - [ ] Preflight cache (`maxAge`) is set to reduce OPTIONS requests
 
+### DNS Rebinding Protection
+
+- [ ] `security.dnsRebindingProtection.allowedHosts` (or `FRONTMCP_ALLOWED_HOSTS`) names the public
+      hostname(s) — on a routable bind the derived default is **not** enforced, and FrontMCP logs a
+      warning saying so
+- [ ] Startup logs show no `DNS-rebinding protection is not enforcing a Host allow-list` warning
+- [ ] Include the port when the public URL uses a non-default one (`api.example.com:8443`)
+- [ ] `allowedOrigins` is set when a browser client connects, so a foreign `Origin` is refused
+
 ### Input Validation
 
 - [ ] All tool inputs use Zod schemas (never trust raw input)

package/catalog/skills-manifest.json

@@ -781,7 +781,7 @@
               "level": "basic",
               "tags": ["config", "browser", "http", "cors", "restricted", "origins"],
               "features": [
-                "Restricting CORS to explicit origins instead of the permissive default",
+                "Naming the origins a browser may read from — omitting `cors` sends no headers at all",
                 "Enabling `credentials: true` with specific origins (required -- browsers reject `*` with credentials)",
                 "Setting `maxAge` to reduce preflight request overhead",
                 "Reading port from an environment variable with a fallback"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontmcp/skills",
-  "version": "1.7.0",
+  "version": "1.7.2",
   "description": "Curated skills catalog for FrontMCP projects",
   "author": "AgentFront <info@agentfront.dev>",
   "homepage": "https://docs.agentfront.dev",