Hardcoded Credentials

What it is

CWE-798 exists when credentials (API keys, database passwords, signing keys, encryption keys, OAuth secrets) are embedded in source code or configuration files committed to version control. Anyone who reads the code, decompiles a binary, or accesses the version-control history obtains the credential.

Why it matters

Hardcoded credentials are the single most common cause of accidental key exposure. Public GitHub repositories are continuously scanned by both defenders and attackers; an AWS key committed to a public repo is typically abused within minutes. Even private repositories are at risk: every employee with read access has the secret, and any historical leak (laptop loss, contractor offboarding) exposes the credential indefinitely. PCI-DSS, HIPAA, and FedRAMP all explicitly prohibit embedding secrets in code.

Common patterns

• AWS access key (AKIA...) or secret access key committed to a config file, even if rotated immediately.
• Stripe, GitHub, Slack, OpenAI, or Anthropic API keys in .env files committed to git.
• Database connection strings with embedded passwords in src/config.ts or application.properties.
• JWT signing secrets defined inline in source rather than loaded from a secret manager.
• OAuth client secrets in mobile-app bundles (recoverable by anyone who downloads the app).
• SSH private keys checked into infrastructure-as-code repositories.

Languages affected

JavaScript, TypeScript, Python, Ruby, Java, Go, PHP, C#, YAML, JSON

What Deva detects

Deva includes high-confidence regex detectors for AWS access keys, Stripe live and test keys (sk_live, sk_test), GitHub personal access tokens (ghp_, github_pat_), Slack tokens (xoxb-, xoxp-), OpenAI keys (sk-proj-), Anthropic keys (sk-ant-), Google Cloud service-account JSON, generic high-entropy strings near variable names like password, secret, key, or token, and SSH private keys (-----BEGIN OPENSSH PRIVATE KEY-----). The scanner runs at every save in the IDE and as a CI step via the dsc CLI, so secrets are caught before they reach a commit.

Example

Vulnerable

import boto3

# Connect to AWS for backups
s3 = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
    region_name='us-east-1',
)

Fixed

import os
import boto3
from botocore.exceptions import NoCredentialsError

# Credentials are loaded automatically from environment variables, IAM role,
# IRSA (Kubernetes), or EC2 instance profile. None of these require code changes.
try:
    s3 = boto3.client('s3', region_name=os.environ.get('AWS_REGION', 'us-east-1'))
except NoCredentialsError:
    raise RuntimeError('AWS credentials not configured. See deployment docs.')

The vulnerable version embeds the AWS access key and secret directly in code. The credential is now in every clone of the repository, every CI build log that prints it, and every developer's laptop. The fix lets boto3 use its standard credential chain: environment variables, IAM role on EC2 / ECS / Lambda, IRSA on EKS, or a profile in ~/.aws/credentials. Secrets live in the deployment environment, not in source. For local development, use direnv or doppler with a secrets manager backend, not committed .env files.

Where this fits in OWASP Top 10

• A04 Cryptographic FailuresSensitive data exposed because cryptography is missing, weak, or misused.
• A07 Authentication FailuresWeak, missing, or improperly implemented authentication.

Compliance framework mapping

Related CWEs

• CWE-259 · Use of hardcoded password specifically.
• CWE-321 · Use of hardcoded cryptographic key.
• CWE-522 · Insufficiently protected credentials.
• CWE-287 · Improper authentication (often a downstream effect).