PluginBench
Skill
Pass
Audit score 90

security

cognitedata/builder-skills

Find and fix security issues in Flows apps before shipping—handles credentials, input validation, XSS, injection, and auth gaps.

What is security?

This skill audits and remediates security vulnerabilities in Flows applications. Use it whenever fixing security issues, hardening features that handle credentials or user input, or before shipping any feature that processes external data. It works through attack-surface mapping, SDK migration, credential hygiene, dangerous DOM APIs, auth gaps, and input validation.

  • Maps attack surface: identifies all routes, auth guards, external data entry points, and write-back operations
  • Migrates all CDF access to the official Cognite SDK, eliminating raw HTTP calls that bypass security controls
  • Finds and removes hardcoded credentials and secrets, replacing them with environment variables
  • Detects and fixes dangerous DOM patterns (dangerouslySetInnerHTML, eval, setTimeout with strings) using DOMPurify
  • Validates authentication and authorization: ensures routes are guarded, tokens are short-lived OIDC, and role checks happen server-side
  • Enforces input validation on forms, URL params, and query strings before CDF calls or DOM rendering

How to install security

npx skills add https://github.com/cognitedata/builder-skills --skill security
Prerequisites
  • A Flows app with src/ directory structure (Vite + React)
  • pnpm or npm package manager
  • Optional: Zod and DOMPurify will be installed automatically if needed
Claude Code
Cursor
Windsurf
Cline

How to use security

  1. 1.Run the skill with an optional file or directory argument (e.g., 'src/auth' or leave blank to audit the whole app)
  2. 2.Review the attack-surface map: routes, auth guards, data entry/exit points
  3. 3.Migrate any raw HTTP calls to CDF to use the official Cognite SDK
  4. 4.Replace hardcoded credentials with environment variables and update .env.example
  5. 5.Wrap dangerous DOM patterns (dangerouslySetInnerHTML, eval) with DOMPurify or refactor to safe alternatives
  6. 6.Verify all routes showing CDF data are behind auth guards and use short-lived OIDC tokens
  7. 7.Add input validation schemas (Zod) for forms, URL params, and query strings before CDF operations

Use cases

Good for
  • Fixing a reported XSS vulnerability in user-generated content rendering
  • Hardening a new feature that accepts file uploads or user form input before shipping to production
  • Auditing an existing app for credential leaks before onboarding new team members
  • Remediating a dependency vulnerability that affects CDF API calls
  • Validating that a new Atlas agent tool or Fusion agent action doesn't expose CDF data to untrusted inputs
Who it's for
  • Flows app developers building features with credential or user-input handling
  • Security engineers conducting pre-release audits of Flows applications
  • Teams remediating reported vulnerabilities or dependency issues
  • Developers integrating Atlas or Fusion agents with CDF data access

security FAQ

What if I have a legitimate fetch() call to a non-CDF API?

Leave it in place but add a comment documenting why it's needed and that it's not a CDF endpoint. The skill will not flag documented third-party API calls.

Do I need to remove all axios or fetch imports?

Only remove them if they're no longer used after migrating CDF calls to the SDK. If you still have non-CDF fetch calls, keep the import.

How do I know if a route is properly auth-guarded?

Check that the route component calls useCogniteClient() and only renders CDF data when the SDK is non-null. If it renders without checking, it's unguarded.

What's the difference between client-side role checks and server-side ACLs?

Client-side checks (hiding UI) are not security—they're UX. Server-side ACLs in CDF prevent unauthorized data access even if the UI is bypassed. Always rely on CDF ACLs for sensitive data.

Can I use a static API key instead of OIDC tokens?

No. Static API keys are long-lived and pose a credential-rotation risk. Always use short-lived OIDC tokens initialized through Flows auth.

Full instructions (SKILL.md)

Source of truth, from cognitedata/builder-skills.


name: security description: "MUST be used whenever fixing security issues in a Flows app, or before shipping any feature that handles credentials, user input, or external data. This skill finds AND fixes security problems — it does not just report them. Do NOT skip this when the user asks for a security fix, security hardening, or vulnerability remediation — run every step in order. Triggers: security, security fix, security hardening, vulnerability, XSS, injection, credentials, secrets, auth, authentication, authorization, token, sensitive data, input validation, CORS, CSP, dependency audit." allowed-tools: Read, Glob, Grep, Shell, Write metadata: argument-hint: "[file or directory to audit, or leave blank to audit the whole app]"

Security Fix

Find and fix security issues in $ARGUMENTS (or the whole app if no argument is given). Work through every step below in order. Every step that finds an issue must also fix it.


Step 1 — Map the attack surface

Read these files before checking anything:

  • src/main.tsx / src/App.tsx — entry point, routing, auth gating
  • vite.config.ts — dev server proxy, CORS, headers
  • package.json — list of third-party dependencies
  • Any file matching **/auth*, **/login*, **/token*, **/credential*

Identify:

  • All pages/routes and whether each is behind an auth guard
  • All places where external data enters the app (CDF SDK calls, fetch, user form input)
  • All places where data is written back (CDF upsert, fetch POST/PUT/DELETE)

Step 2 — Migrate all CDF access to the Cognite SDK

All traffic to Cognite Data Fusion (CDF) must go through the official Cognite SDK. Find any HTTP, WebSocket, or other network call to CDF-like hosts or APIs that bypasses the SDK and rewrite it to use the SDK.

Search for raw HTTP calls

# Find fetch, axios, XMLHttpRequest, and other HTTP client usage
grep -rn --include="*.ts" --include="*.tsx" --include="*.js" \
  -E "(fetch\(|axios\.|axios\(|XMLHttpRequest|\.ajax\(|http\.get\(|http\.post\(|request\()" src/

# Find raw URL construction that looks like CDF endpoints
grep -rn --include="*.ts" --include="*.tsx" \
  -E "(cognitedata\.com|cognite\.ai|/api/v1/projects|cdf\.|\.cognite\.)" src/

# Find custom Authorization or api-key headers
grep -rn --include="*.ts" --include="*.tsx" \
  -E "(Authorization|api-key|apikey|x-api-key)" src/ | grep -v "node_modules"

How to fix

For each raw CDF call found, read the surrounding code to understand what CDF resource and operation it targets, then rewrite it using the appropriate SDK method. Remove the raw HTTP client import if it's no longer used.

PatternAction
fetch() or axios call to a CDF URL (*.cognitedata.com, /api/v1/projects/*)Rewrite to use the Cognite SDK (cognite.files.getDownloadUrls(...), cognite.timeseries.retrieve(...), client.instances.search(...), etc.)
Custom Authorization header with a CDF tokenRemove — the SDK handles auth automatically
WebSocket connection to CDF endpointsRewrite to use SDK streaming methods
Proxy endpoint that forwards to CDF internallyRewrite the proxy to use the SDK internally
fetch() to a non-CDF URL (static assets, documented third-party API)Leave — but add a comment documenting why it's needed

After rewriting all CDF calls, remove any axios or fetch-related imports that are no longer used.

What is acceptable

  • All CDF reads/writes through sdk.files.*, sdk.timeseries.*, client.instances.*, etc.
  • Non-CDF network calls that are:
    • To known static asset hosts (CDNs, image services)
    • To documented third-party APIs required by the product
    • Explicitly noted in the app's README or architecture docs

Step 3 — Find and fix credential & secret hygiene

Search for hard-coded credentials and sensitive values:

# Look for anything that smells like a secret in source files
grep -rn --include="*.ts" --include="*.tsx" --include="*.js" \
  -E "(password|secret|apikey|api_key|token|bearer|private_key)\s*=\s*['\"]" src/

For each hardcoded secret, replace it with an environment variable. Create or update .env.example with a placeholder. Add .env to .gitignore if missing.

How to fix

  1. Replace each hardcoded secret with an import.meta.env.VITE_* reference. For example:

    • const apiKey = "sk-abc123" → const apiKey = import.meta.env.VITE_API_KEY
    • const token = "eyJhbG..." → const token = import.meta.env.VITE_AUTH_TOKEN
  2. Add the variable to .env.example with a placeholder value (e.g., VITE_API_KEY=your-api-key-here). Create .env.example if it doesn't exist.

  3. Ensure .env and .env.local are in .gitignore — add them if missing.

  4. Remove any console.log, console.error, or similar calls that print a CDF token, user object, or API key.


Step 4 — Find and fix dangerous DOM APIs

Search for patterns that allow arbitrary script execution or HTML injection:

grep -rn --include="*.tsx" --include="*.ts" \
  -E "dangerouslySetInnerHTML|innerHTML\s*=|eval\(|new Function\(|setTimeout\(['\"]|setInterval\(['\"]" src/

For each dangerous DOM pattern, apply the fix directly. Install DOMPurify with pnpm add dompurify and pnpm add -D @types/dompurify if needed.

How to fix

  • dangerouslySetInnerHTML: Wrap the value with DOMPurify.sanitize(). Add import DOMPurify from 'dompurify' to the file. Example:

    // Before
    <div dangerouslySetInnerHTML={{ __html: userContent }} />
    // After
    import DOMPurify from 'dompurify';
    <div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />
    
  • eval() / new Function(): Rewrite using a data-driven approach. Use JSON.parse() for data parsing, or a lookup table / switch statement for dynamic logic dispatch. Never pass user-controlled strings to code evaluation.

  • setTimeout/setInterval with a string argument: Convert to a function reference:

    // Before
    setTimeout("doSomething()", 1000)
    // After
    setTimeout(() => doSomething(), 1000)
    

Step 5 — Find and fix authentication & authorization gaps

Read the auth setup (likely src/contexts/, src/hooks/, or setup-flows-auth output):

  • Every route that shows CDF data must be behind the Flows auth guard (useCogniteClient returns a non-null sdk before rendering).
  • The CDF client must be initialized with short-lived OIDC tokens, not a static API key.
  • User role/capability checks must happen server-side (CDF ACLs) — do not rely solely on hiding UI elements.

Check Atlas / agent:

  • Prefer EOS sidebar (integrate-fusion-agent); in-app useAtlasChat is exception-only
  • agentExternalId not from user input; validate tool/action args before CDF queries
  • No third-party LLM APIs with CDF data; no uncapped completions over query results (5 / max 50, cached)

How to fix

For each unguarded route that shows CDF data, wrap it with the auth guard component. For example, ensure the route element is wrapped in a component that checks useCogniteClient and renders a loading/login state when the SDK is not ready.

For Atlas tool execute functions and Fusion agent action handlers, add argument validation at the top of each function. Validate that each args field is the expected type and within expected bounds before using it in any CDF query.


Step 6 — Find and fix input validation gaps

Every value that comes from a form, URL param, or query string before it reaches a CDF call or is rendered to the DOM must be validated:

# Find useSearchParams, URLSearchParams, and form onChange handlers
grep -rn --include="*.tsx" --include="*.ts" \
  -E "useSearchParams|URLSearchParams|searchParams\.get|e\.target\.value" src/

For each unvalidated external input, add runtime validation. Install Zod if not present (pnpm add zod). Create a schema that matches the expected shape and use .safeParse() instead of type casts.

How to fix

  1. Add Zod schemas for URL params and form inputs. Example:

    import { z } from 'zod';
    const paramSchema = z.object({
      id: z.string().min(1),
      page: z.coerce.number().int().positive().default(1),
    });
    const result = paramSchema.safeParse({ id: searchParams.get('id'), page: searchParams.get('page') });
    if (!result.success) { /* handle error */ }
    
  2. Replace as MyType casts on external data with Zod .safeParse() — never trust data from URL params, form inputs, or API responses without validation.

  3. Add nullish fallbacks for searchParams.get() — always handle the case where the param is missing or empty.


Step 7 — Find and fix Vite / server configuration

Read vite.config.ts and any server.ts / express.ts files.

How to fix

Add any missing security headers to the vite.config.ts server.headers section. If the section doesn't exist, create it. The minimum required headers are:

server: {
  headers: {
    'Content-Security-Policy': "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.cognitedata.com",
    'X-Frame-Options': 'DENY',
    'X-Content-Type-Options': 'nosniff',
  },
}

Adjust the Content-Security-Policy to match the app's actual needs (e.g., adding specific CDN hosts for fonts or images).

Also:

  • Remove any define entries in vite.config.ts that embed raw secrets into the bundle. Use import.meta.env instead.
  • Confirm the dev proxy (server.proxy) does not expose internal endpoints in production builds.

Step 8 — Find and fix dependency vulnerabilities

pnpm audit --audit-level=high

How to fix

  1. Run pnpm audit fix first to auto-fix what's possible.
  2. For any remaining high/critical CVEs, manually update the package version in package.json and run pnpm install.
  3. If a vulnerable package has no fix available, document it as a known risk and check if there's an alternative package.

Step 9 — Report remaining findings

Report only issues that could not be auto-fixed (e.g., architectural decisions that need human judgment, packages with no available fix, or patterns that require significant refactoring).

Summarize what was fixed in each step:

StepWhat was fixedRemaining issues
2 — CDF SDKMigrated N raw calls to SDK(any that couldn't be migrated)
3 — CredentialsReplaced N hardcoded secrets with env vars(any that need human decision)
4 — DOMSanitized N dangerous patterns(any that need refactoring)
5 — AuthWrapped N unguarded routes(any architectural gaps)
6 — ValidationAdded Zod schemas to N inputs(any that need custom logic)
7 — Vite configAdded N security headers(any CSP tuning needed)
8 — DependenciesFixed N vulnerable packages(any with no available fix)

If any remaining issues require immediate action before deployment, list them explicitly.


Done

State what was fixed and confirm the app is more secure. List any remaining items that require human judgment before the next deployment.