SFCC Dev

MCPv1
Rhino InquisitorBlogGitHub
Security & Privacy

Built-In Guardrails – You Add Discipline

Opinionated local-only design: minimal credential footprint, scoped API access, defensive parsing. Use this page as a practical hardening checklist, not a marketing overview.

Surface: 36+ specialized tools (docs, best practices, SFRA, cartridge gen, runtime logs, job logs, system & custom objects, site preferences, code versions)

Local Only

Never deploy to shared or production infra. No multi-user isolation layer exists.

Least Privilege

Grant only OCAPI resources you actively need.

No Persistent Secrets

Credentials live in memory during execution; you own filesystem storage strategy.

🔐 Modes & Security Characteristics

Both modes are designed for local single‑developer use. Docs mode has a zero credential surface; Full Mode’s profile is essentially the same as any normal SFCC development workflow using a dw.json for OCAPI + WebDAV access. Choose based on capability needs, not fear—just scope credentials sensibly.

DDocs Mode (Default)

  • ❇

    No credentials required

    Pure static: zero auth surface

  • 📄

    Static content only

    Docs, guides, cartridge scaffolding

  • 🧱

    No outbound authenticated calls

    Nothing to leak or revoke

  • 🧪

    Safe capability exploration

    Great for AI tool schema discovery

  • �

    Instant reversible baseline

    Add credentials later without refactor

Baseline mode: zero credential management, ideal first run.

FFull Mode (--dw-json)

  • 🔑

    Credential parity

    Same auth data you already use locally

  • 🪵

    Runtime + job logs

    Tail, search, summarize – read-only WebDAV access

  • 🧭

    System & custom object metadata

    OCAPI Data API – attribute & group definitions

  • ⚙️

    Site preference discovery

    Group-scoped search with masked password values

  • 🚦

    Explicit code version activation

    Never automatic; requires targeted command

  • 🪄

    Cartridge generation + docs

    Same as docs mode plus live capabilities

Comparable risk to normal SFCC dev with dw.json; treat scope hygiene the same.
Switch between modes freely: omit --dw-json to return to a zero‑credential baseline.

📋 Baseline Hardening Checklist

Perform these once per environment. Keep it lightweight; delete unused credentials.

  1. 1Confirm sandbox hostname (never production domain).
  2. 2Add dw.json + *.dw.json to .gitignore and verify not tracked.
  3. 3chmod 600 dw.json (owner read/write only).
  4. 4Remove unused OAuth fields if only using logs.
  5. 5Grant only required OCAPI resources (add incrementally).
  6. 6Mask secrets with environment overrides in CI contexts.
  7. 7Run docs mode first; validate tool set boundaries.
  8. 8Rotate client secret + password on schedule (quarterly baseline).

🛡️ Credential Handling

You retain full control of persistence. The server reads your dw.json once, hydrates in-memory configuration, and performs authenticated calls. No outbound exfiltration logic exists.

Minimize Scope

  • Start w/ no Data API resources
  • Add system objects only when needed
  • Remove stale resources quarterly

Protect Files

  • chmod 600 dw.json
  • Avoid shared directories (Sync/Drive)
  • Do not email secrets

Rotate & Audit

  • Quarterly secret rotation baseline
  • Remove orphaned API clients
  • Track creation dates (label names)

🧪 Practical Threat Model (Local Context)

In a single‑developer local setup the incremental risk introduced by Full Mode is roughly equivalent to any normal use of dw.json. Core concerns remain credential scope creep, accidental sharing of log snippets containing business data, and copying sensitive preference values externally. Below: built‑in mitigations vs. your ongoing hygiene tasks.

Mitigated In Design

  • ✔Path traversal (validated absolute paths)
  • ✔Parameter schema/type validation
  • ✔Read-only log operations (no writes)
  • ✔Scoped tool registration (no dynamic eval)
  • ✔Token refresh w/ expiration handling
  • ✔Memory-only caching (no disk persistence)

Your Responsibilities

  • ⚠Do not run on shared multi-user servers
  • ⚠Keep secrets out of version control
  • ⚠Avoid copying raw logs with PII into tickets
  • ⚠Limit OCAPI resources to active feature work
  • ⚠Rotate credentials + revoke unused clients
  • ⚠Disable debug once diagnosing finished

Docs Mode

Static reference + generation only. Zero credential or data surface.

Full Mode (Scoped)

Typical local dev parity: targeted OCAPI, selective log tailing, metadata queries.

Broad Scope (Review)

Wide OCAPI grants + continuous debug + indiscriminate log sharing. Still local—but audit and prune.

💾 Data Handling & Privacy

Runtime data (logs, attribute listings, preference search results) is streamed, parsed, optionally cached in memory, and discarded on process exit.

Design Principles

  • No silent disk writes
  • Bounded tail reads (~200KB)
  • Optional debug noise suppression

Log Processing

  • Tail/range reads only (≈200KB)
  • Pattern search constrained by limit
  • Analyzer strips obvious secret tokens

Preference Values

  • Password types masked (no bypass)
  • Group-limited search scope
  • No storage of raw values

System & Custom Objects

  • Metadata only (ids, flags, counts)
  • No record-level PII retrieval
  • You control query breadth

🔍 Responsible Disclosure

Found a vulnerability? Help strengthen the ecosystem—avoid public zero-days.

  1. Do NOT open a public GitHub issue containing exploit details.
  2. Email maintainers with: version, environment, reproduction steps, impact summary.
  3. Suggest a remediation direction if obvious (helps triage).
  4. Allow a reasonable patch window before disclosure.
  5. Re-test once patch is published; confirm mitigation completeness.

🔗 Next Steps

Keep momentum: refine configuration or explore advanced tooling now that baseline security posture is set.

Configuration Guide→Explore FeaturesSee Examples