Fix credential hardcoded in source in SvelteKit

A credential appears as a literal in source. Anything committed is in the repository's history, in every clone, and in every build artefact, so removing the line later does not revoke it. Read secrets from the environment or a secret manager, and rotate anything that has been committed.

high likely SvelteKit CWE-798 / OWASP A07:2021

The vulnerable pattern in SvelteKit

This finding comes from the SvelteKit fixture in the owlwarden test suite. This literal carries the prefix of a Stripe live secret key, so it is a real credential rather than a placeholder. It is in the repository's history and in every clone; deleting the line does not revoke it.

The corrected handler

Read it from `$env/dynamic/private`, which SvelteKit refuses to import into client code - that refusal is the point.

import { env } from '$env/dynamic/private'

const stripeKey = env.STRIPE_KEY
if (!stripeKey) throw new Error('STRIPE_KEY is not set')

On a different runtime

The fix above is written for the runtime SvelteKit usually runs on. These are the runtimes where it would not run at all - an import that does not exist, or an API the host does not have - and what to write instead.

Workers and other fetch-API runtimes

There is no process.env on this runtime. Read the value from the binding the host passes the handler, and declare it as a secret rather than a plaintext var.

// wrangler.toml / .dev.vars declare it; the handler receives it.
export default {
  async fetch(request: Request, env: { API_KEY: string }) {
    const key = env.API_KEY
    if (!key) throw new Error('API_KEY is not bound')
    return handle(request, key)
  },
}

If you are not using SvelteKit

Move the value into an environment variable or a secret manager, and rotate it - once committed it is in the history and in every clone, so removing the line does not revoke it.

Check your own repository

npx owlwarden scan
npx owlwarden explain hardcoded-secret

Runs on your machine. No account, no telemetry, no network unless you ask. In CI, SARIF uploads to code scanning and the exit code is the gate.

Other SvelteKit checks

Rules with a tested SvelteKit example.

• cors-permissive medium Cross-origin policy accepts any origin
• insecure-cookie medium Cookie set without its protective attributes
• install-lifecycle-script medium Package declares an install-time script
• open-redirect medium Redirect target comes from the caller
• security-headers-missing medium Security headers are not configured
• sensitive-data-logged medium Sensitive data written to a log
• sql-injection high SQL query built by string interpolation
• ssrf high Server fetches a URL the caller controls
• stack-trace-leak high Stack trace leaked in error response
• weak-crypto high Broken cryptographic primitive protecting a secret

hardcoded-secret for every framework / All rules / owlwarden