Security Review

Integration: Webflow
Repository: https://github.com/slimslenderslacks/mcp-server
Commit: latest
Scan Date: 2026-03-13 16:45 UTC

Security Score

80 / 100

Tier Classification

Silver

OWASP Alignment

OWASP Rubric

• Standard: OWASP Top 10 (2021) aligned review
• Core methodology: architecture context, trust boundaries, data-flow tracing, threat modeling, control verification, and evidence-backed validation
• Key characteristics considered: exploitability, impact, likelihood, attacker preconditions, and business context

OWASP Security Category Mapping

• A01 Broken Access Control: none
• A02 Cryptographic Failures: none
• A03 Injection: none
• A04 Insecure Design: none
• A05 Security Misconfiguration: none
• A06 Vulnerable and Outdated Components: none
• A07 Identification and Authentication Failures: none
• A08 Software and Data Integrity Failures: none
• A09 Security Logging and Monitoring Failures: none
• A10 Server-Side Request Forgery: none

Static Analysis Findings (Bandit)

High Severity

None

Medium Severity

None

Low Severity

None

Build Status

SKIPPED

Build step was skipped to avoid running untrusted build commands by default.

Tests

Not detected

Documentation

README: Present
Dependency file: Present

AI Security Review

OWASP-Aligned Security Review of repository: Webflow (webflow-mcp-server)

1) OWASP Review Methodology Applied
- Architecture & Context: I inspected the repository root and the main TypeScript entry (src/index.ts), plus package.json and .gitignore to understand how the integration runs (a Model Context Protocol (MCP) server exposing tools that call the Webflow API using a Webflow API client and a credentials token taken from the environment).
- Trust Boundaries & Entry Points: The MCP server receives tool invocation messages over a Stdio transport (stdin/stdout). Each server.tool handler is an entry point that accepts parameters (validated using zod in many places). The Webflow API (webflow-api library) is an external trust boundary (outbound network calls).
- Data Flows: I traced how inputs from the MCP messages flow through zod validation schemas into client API calls, and how responses are returned (JSON.stringify(response) placed in the tool response content). I searched for use of environment variables, filesystem or subprocesses, and dynamic evaluation.
- Threat Modeling: I modeled an attacker who can craft MCP tool requests (i.e., the agent or client that speaks MCP on stdin) and a remote attacker who might obtain or misuse the WEBFLOW_TOKEN. I looked for injection, unsafe deserialization, SSRF, secrets leakage, and misconfiguration issues.
- Verification: For each finding I provided concrete file and line references where the behavior appears. I verified use of zod schemas, use of process.env, calls to WebflowClient, and the returning of raw JSON responses.

2) OWASP Top 10 2021 Category Mapping
- A01 Broken Access Control: exposure of powerful Webflow operations (create collections/fields/items, publish sites) without per-tool authorization controls.
- A02 Cryptographic Failures: environment token management and potential token leakage in returned responses (sensitive data exposure rather than cryptographic algorithm misconfiguration).
- A05 Security Misconfiguration: lack of error handling, no response sanitization, and no runtime hardening (rate limiting, request throttling) visible.
- A06 Vulnerable and Outdated Components: third-party deps (webflow-api, @modelcontextprotocol/sdk, zod) should be audited for vulnerabilities.
- A08 Software and Data Integrity Failures: no integrity checks for dependencies (no lockfile related policies indicated beyond package-lock.json being present) and no verification of inbound payloads beyond permissive zod patterns in certain schemas.
- A09 Security Logging and Monitoring Failures: no logging or alerting for sensitive operations or failed calls; unhandled exceptions may crash the process.
- A10 Server-Side Request Forgery (low likelihood): limited direct, but passing attacker-controlled strings into an API client that makes outbound requests risks abuse if that client supports flexible host overrides (not in the code but worth noting).

3) Critical Vulnerabilities
No direct, immediate critical issues (RCE, unsafe eval, command execution, SQL injection, unsafe deserialization) were found in the code itself.
Evidence: No use of eval/child_process/exec/new Function. (search for exec/child_process returned none). The application only uses the webflow-api client to perform HTTPS requests.

4) High Severity Issues
- Broken access controls / excessive privileges (A01)
- File: src/index.ts
- Evidence: The server exposes many powerful tool handlers (publish site, create collections, add fields, create/publish items) that will run with the single WEBFLOW_TOKEN the process holds. Any MCP client that can send messages to this server (over stdio here, typically a local agent) can call these handlers.
- Lines: tools are registered across the file; for example pages: sites_publish (src/index.ts lines ~43-54), collections_create (~313-321), collection_fields_create_* (~334-360), collections_items_create_item (~504-513), collections_items_publish_items (~573-582). See server.tool(...) occurrences at multiple lines (search results show many: src/index.ts:29,37,51,74...591).
- Severity: High (Privileges allow destructive actions: create fields, publish sites).
- Impact: A malicious or compromised agent/client could modify or publish site content, add fields, or otherwise alter the customer's Webflow site.
- Remediation: Enforce per-tool authorization and least privilege. Require an explicit allowlist or token-scoped access for different operations. If the MCP ecosystem supports per-invocation signed claims/claims-based access control, use that to authorize operations. Otherwise implement a gating mechanism (e.g., require an approval step for destructive tools).

• Sensitive token exposure via returned API responses (A02 / A09)
• File: src/index.ts
• Evidence: Every tool returns JSON.stringify(response) unfiltered and places it in content: [{ type: "text", text: JSON.stringify(response) }]. If any Webflow API response contains sensitive fields (webhook secrets, API tokens, or internal IDs), those are returned verbatim to the caller/agent.
• Examples (lines): e.g., sites_list handler returns JSON.stringify(response) (src/index.ts:29-33), sites_get (src/index.ts:37-46), and many others (see JSON.stringify matches at many lines; e.g. src/index.ts:32,45,64...).
• Severity: High (token or secret leakage could enable attacker to fully take over Webflow resources).
• Remediation: Sanitize responses before returning. Implement allowlists for fields to return (e.g., return only IDs, names, status) and redact sensitive values. If passing full responses to an LLM is required, ensure it's safe to do so (prefer sanitized summaries).

5) Medium Severity Issues
- Overly permissive input schema using z.record(z.any()) (A03/A01)
- File: src/index.ts
- Evidence: Several collection item schemas accept fieldData: z.record(z.any()) (src/index.ts:397, 518, 559). This allows arbitrary nested objects as field data. While some fields are inevitable, allowing arbitrary values increases risk that unvalidated or malicious content is sent to Webflow (creation of fields with unexpected content, or embedding links/payloads that later cause abuse).
- Lines: as above (search results show fieldData matches at lines 397, 518, 559).
- Severity: Medium.
- Remediation: Tighten schemas to only accept expected field types. If fieldData is truly free-form because collections have custom fields, then validate and sanitize nested values where possible; otherwise require a shape or white-list allowed properties.

• No explicit error handling / process resilience (A05 / A09)
• File: src/index.ts
• Evidence: Each handler calls the webflow client and returns the response, but there are no try/catch blocks to catch and normalize exceptions. Unhandled exceptions could crash the MCP server or leak internal stack traces to the caller.
• Lines: Multiple handlers (e.g., first handler at src/index.ts:29-33, subsequent handlers with await client.* without try/catch throughout file).
• Severity: Medium.

• Remediation: Wrap calls in try/catch, return well-formed error messages without internal details, and log errors to a secured logging backend. Consider process supervisors and graceful restart.

• No input validation for certain optional parameters (A03)

• File: src/index.ts
• Evidence: Many parameters are typed as z.string() or z.number(), which is good. However some array parameters (e.g., publish customDomains: z.string().array().optional()) will accept any string. There are no checks for length, character set, or maximum array size. This could allow huge payloads.
• Lines: e.g., sites_publish schema around src/index.ts:51-63.
• Severity: Medium / Low depending on backend protections.
• Remediation: Add bounds checks and strict validation (max length, max array size, allowed characters) on inputs that will be forwarded to external APIs.

6) Low Severity Issues / Best-practice gaps
- Lack of logging and monitoring (A09)
- File: src/index.ts
- Evidence: No logging statements or metrics emitted; .gitignore includes .env (good), but runtime visibility is missing.
- Severity: Low.
- Remediation: Add structured logs for important events (tool invocation, failures, unauthorized attempts), integrate monitoring and alerting.

• No dependency vulnerability auditing mentioned (A06)
• File: package.json
• Evidence: Dependencies include webflow-api ^3.1.1, @modelcontextprotocol/sdk ^1.8.0, zod ^3.24.2. No vulnerability policy or automated scanning mentioned in CI workflow (CI file exists but not analyzed here). package-lock.json is present (good), but ensure regular npm audit / SCA.
• Severity: Low.

• Remediation: Run npm audit, pin dependencies, adopt SCA tooling in CI.

• Returning raw Webflow responses to the MCP caller may create excessive information leakage even if the responses are not secrets (A02)

• File: src/index.ts (multiple locations returning JSON.stringify(response)).
• Severity: Low.
• Remediation: Return concise responses (IDs, status) and keep verbose debug info gated behind a debug/logging flag.

7) Key Risk Characteristics (for prioritized findings)
- Broken access control / excessive privileges
- Exploitability: High if an attacker can submit MCP requests to this process (e.g., a compromised agent or malicious model tooling). The transport is stdio, which typically means the server is locally launched by a user; however if the process is run in an environment where agent input is not fully controlled, attacker can invoke.
- Impact: High — attacker can modify/publish site content and configuration.
- Likelihood: Medium — depends on deployment; if the server runs locally for a single developer, likelihood is lower; if run in shared CI or cloud environment, likelihood is higher.
- Preconditions: Access to the MCP stdio input channel (usually the model/agent environment) or access to the machine/process.

• Sensitive token exposure via returned API responses
• Exploitability: Medium — depends on whether Webflow API returns sensitive fields in responses. Even if not common, future API changes may expose metadata.
• Impact: High if secrets are present — could lead to full account takeover.
• Likelihood: Low–Medium currently but non-zero.

• Preconditions: Ability to call server tools and receive the returned JSON content.

• Overly permissive z.record(z.any())

• Exploitability: Medium — malformed or large payloads might be used to cause unexpected behavior server-side or store harmful content.
• Impact: Medium — may allow attacker to inject malicious content into CMS items that are later served to site visitors or to the API.
• Likelihood: Medium if arbitrary agent input is allowed.
• Preconditions: Ability to call endpoints that accept request bodies (collections items creation/update).

8) Positive Security Practices Observed
- Use of zod for schema validation: The code uses zod extensively to validate inputs for most handlers (good practice to enforce expected types).
- Environment token usage: The code fails fast if the required WEBFLOW_TOKEN environment variable is missing (lines src/index.ts:8-10), preventing accidental runs without credentials.
- .gitignore includes .env and node_modules (prevents accidental commit of environment file tokens).
- No usage of eval or child process spawning; avoids common RCE vectors.

9) Recommendations (concrete fixes with file:line references and OWASP context)
- Implement per-tool authorization and least privilege (A01 Broken Access Control)
- Files/lines: src/index.ts (tool registrations throughout; examples at 29-33, 51-54, 313-321, 334-360, 504-513, 573-582).
- Fix: Add an authorization check wrapper around server.tool handlers which inspects caller identity/claims (if MCP tokens or connector metadata are available) and enforces role/operation allowlists. If caller identity is unavailable, require interactive approval for destructive operations such as publishing or creating collections. E.g., wrap the handler body in a function that does: await authorize(caller, 'sites_publish', site_id) and return 403-like MCP error if unauthorized.

• Sanitize and redact Webflow API responses before returning to the caller (A02 Sensitive Data Exposure)
• Files/lines: All occurrences where response is returned raw. Examples: src/index.ts lines ~29-33, 37-46, 64-72, etc. (search results for JSON.stringify occurrences show exact lines: 32,45,64,89,104,156,177,215,233,247,321,334,347,360,381,422,466,504,545,585,602).

• Fix: Create a response sanitizer function that removes keys known to contain secrets (e.g., access tokens, webhook secrets, internal configuration) and limits depth and size. Return a sanitized object or a small summary (IDs, names, status). Use content negotiation to allow full response only when explicitly requested by an authenticated admin with an audit trail.

• Remove or tighten use of z.record(z.any()) (A03 Injection / A05 Misconfiguration)

• Files/lines: src/index.ts: lines ~397, 518, 559 (these are the search hits for fieldData).

• Fix: Replace z.record(z.any()) with a more specific union of allowed primitive types (string, number, boolean, arrays of these) or a recursive schema with whitelisted keys. If the collection schema must be dynamic, require a per-collection schema registration step that defines the allowable fields and types, and validate against that.

• Add robust error handling and structured logs (A05, A09)

• Files/lines: Handler blocks throughout src/index.ts (e.g., first handler at 29-33).

• Fix: Wrap outbound calls in try/catch. On error, log a structured event with minimal sensitive data and return a sanitized failure to the caller. Integrate with a logging/monitoring service and include metrics and crash reporting.

• Input validation improvements: enforce limits (max string length, max array size) and character whitelists for parameters forwarded to Webflow (A03)

• Files/lines: e.g., sites_publish arguments (src/index.ts ~51-63), pages_list (src/index.ts ~74-92), etc.

• Fix: Use z.string().min(1).max(N) for IDs and slugs, add z.array(z.string().max(256)).max(10) for arrays, and z.number().int().min(0) for offsets.

• Audit dependencies and enable automated SCA in CI (A06)

• File: package.json

• Fix: Run npm audit / use GitHub Dependabot or Snyk, pin dependencies where appropriate, and add a CI step to fail builds on high/critical vulnerabilities.

• Avoid returning very large JSON blobs (A05/A09)

• Files/lines: every return of JSON.stringify(response).

• Fix: Implement pagination and size limits on returned payloads; truncate responses and provide references/IDs for fetching more if needed. Consider returning summaries rather than raw responses.

• Document and enforce secure runtime deployment practices

• Files/lines: README.md (not examined in detail for deployment guidance)
• Fix: Add README guidance on running locally vs in CI, ensure WEBFLOW_TOKEN scope is minimal, and recommend not running this server in multi-tenant/shared environments without additional authorization controls.

10) Next Tier Upgrade Plan
- Current tier: Bronze (functionally complete but lacking security controls). Rationale: The integration correctly validates many inputs with zod, uses environment secrets properly and avoids dangerous constructs, but lacks authorization controls, response sanitization, error handling, and observability.

• Next target: Silver. Objectives to reach Silver (prioritized):
  1) Implement per-tool authorization gating and least privilege model. (High priority) — add an authorization wrapper that inspects caller metadata and requires explicit allow for destructive tools (publish/create/update/delete).
  2) Sanitize/field-filter Webflow API responses before returning them to callers, and add an explicit admin-only verbose mode behind strong auth. (High priority)
  3) Tighten input schemas, removing z.record(z.any()) and adding size/character limits. (Medium priority)
  4) Add try/catch and structured logging, integrate monitoring, and ensure process resilience. (Medium priority)
  5) Add dependency scanning to CI, pin critical dependencies and address any discovered vulnerabilities. (Low–Medium priority)

• Actions to reach Gold (after Silver):

• Introduce audit logging with tamper-evidence for sensitive operations (publish/create/delete). Keep audit logs in an immutable store.
• Provide granular tokens with Webflow that are scoped to minimal required operations and rotate tokens automatically.
• Harden the runtime (drop privileges, run under a dedicated user, use secrets manager instead of env vars when deployed in shared environments).
• Add E2E tests validating that unauthorized callers cannot perform destructive actions.

Summary of Concrete Fixes with file/line references
- Sanitize all returned responses to avoid secret leakage (src/index.ts: lines with JSON.stringify — e.g., 32,45,64,89,104,156,177,215,233,247,321,334,347,360,381,422,466,504,545,585,602). Replace direct JSON.stringify(response) with sanitizeResponse(response).
- Add authorization wrapper for server.tool handlers (wrap handlers declared at src/index.ts:29,37,51,74,95,143,162,202,225,239,313,326,339,352,372,410,454,472,533,573,591 — see server.tool search results). Implement authorize(caller, action, resource) checks.
- Tighten zod schemas where z.record(z.any()) is used (src/index.ts lines ~397, 518, 559). Use explicit typed field types or per-collection validation.
- Add try/catch to every handler call to normalize errors and avoid leaking internal stack traces (handlers throughout src/index.ts).
- Add structured logs and monitoring for tool invocations and failures.
- Add npm audit / Dependabot integration to package.json/CI and address any critical findings.

Final notes and risk posture
- The code is small and well-structured; it avoids dangerous constructs like eval and child_process, and uses zod for many inputs. The highest risk is operational: the MCP tool surface exposes powerful Webflow operations executed under a single token. Without authorization gating and response sanitization, a malicious or compromised agent could perform destructive actions and potentially extract sensitive data.

If you’d like, I can: provide a patch/PR that implements a response sanitizer helper and a generic authorization wrapper function and show example modifications to 2-3 key handlers (e.g., sites_publish and collections_items_create_item) to demonstrate recommended controls.

Summary

Security Score: 80/100 (Silver)
Static analysis found 0 high, 0 medium, and 0 low severity issues.
Build step skipped for safety.
No automated tests detected.