API keys and secrets hardcoded in the code

The special case of AWS keys

An exposed AWS access key (prefix AKIA or ASIA) can grant access to S3 buckets, databases, or any other resource depending on the attached IAM permissions — an automated scan always treats it as critical, regardless of context.

The fix

Move every secret key to a server-side environment variable — never prefixed NEXT_PUBLIC_ (or VITE_), which explicitly tells the bundler to include it in the client code.

// Bad — ends up in the client bundle
const apiKey = "sk-abc123...";

// Good — server-only variable
const apiKey = process.env.SOME_SECRET_KEY;

For AWS keys specifically, prefer temporary identities (STS) with minimal permissions over static access keys, even server-side.

What doesn't count as a leak

Some values look like secrets but are public by design: the Supabase anon key, the Stripe publishable key (pk_live_), and Firebase's apiKey config — their security relies on server-side rules (RLS, Security Rules), not on the value itself being secret.