Mobb User Docs
Start NowBlogsWatch NowContact Us
  • What is Mobb?
  • What's New with Mobb
  • Supported Fixes
  • Getting Started
    • System Requirements
    • Onboarding Guide
      • Registering a Mobb account
      • Try Mobb now!
      • Running Mobb against your own code
      • Automate Mobb in a CI/CD pipeline
    • Working with the Fix Report
    • Mobb CLI Overview
      • Analyze Mode
      • Scan Mode
      • Add SCM Token Mode
      • Review Mode
      • Common Deployment Scenarios
  • Mobb Dashboard
  • Integrating SAST Findings
    • Checkmarx
      • Generating Checkmarx One JSON Report from CLI
    • Snyk
    • SonarQube
      • Generating a SonarQube SAST Report
    • Fortify
    • CodeQL
    • Semgrep/Opengrep
      • Generating a Semgrep SAST Report
      • Generating an Opengrep SAST Report
  • CI/CD Integrations
    • GitHub Actions
      • GitHub Fixer for CxOne
      • GitHub Fixer for Opengrep
    • GitLab Pipeline
    • Azure DevOps
    • Jenkins
    • CircleCI
    • Bamboo
    • Bitbucket Pipeline
  • Administration
    • User Management
    • Project Settings
    • Access Tokens
    • Organization-Level Fix Policy
    • Integrations Page
    • SAML Single Sign-On Flow
  • More Info
    • Mobb Broker
      • Mobb Broker Token Rotation
      • Secure storage of Mobb broker in AWS Secrets Manager
    • Providing Fix Feedback
    • Frequently Asked Questions (FAQ)
    • Data Protection and Retention
    • Service Level Agreement
  • Fixing Guides
    • SQL Injection
    • Path Traversal
    • Log Forging
    • XSS
    • XXE
    • Server Side Request Forgery
    • HttpOnly Cookie Vulnerabilities
    • Hardcoded Domain in HTML
    • Hardcoded Secrets
    • HTTP Response Splitting Attacks
    • Insecure Cookie Vulnerabilities
    • Insecure Randomness
    • Missing Check against Null
    • Missing Rate Limiting
    • Regex Missing Timeout
    • System Information Leakage
  • Mobb REST API Guide
Powered by GitBook
On this page
  • What are Hardcoded Secrets and How Do They Impact Security?
  • One Simple Hardcoded Secret Example
  • Hardcoded Secrets Prevention Methods: How to Fix Your Code
  • Code Samples
  • Need more help in preventing Hardcoded Secrets?
  • We'd love your feedback!

Was this helpful?

  1. Fixing Guides

Hardcoded Secrets

Learn how to prevent hardcoded secrets in your code with real examples and best practices. Protect your applications from exposing sensitive credentials and API keys.

Tools recognizing this:

Opengrep Fortify Checkmarx SonarQube Snyk Semgrep CodeQL

What are Hardcoded Secrets and How Do They Impact Security?

Hardcoded secrets are sensitive credentials, API keys, or passwords that are directly embedded in source code. This is a significant security risk as it can expose sensitive information to unauthorized users, especially when code is shared or made public.

The risks of hardcoded secrets include:

  • Exposure of sensitive credentials in version control systems

  • Difficulty in rotating or changing credentials

  • Potential unauthorized access to systems and services

  • Compliance violations and security audit failures

This guide covers hardcoded secrets, examples, prevention methods, and how to properly manage sensitive credentials in your applications.

One Simple Hardcoded Secret Example

Consider this common example of hardcoded credentials:

const dbConnection = mysql.createConnection({
    host: 'localhost',
    user: 'admin',
    password: 'secretP@ssw0rd123!'
});

This exposes the database credentials directly in the code, making them:

Visible to anyone with code access

The credentials should instead be stored in:

Environment variables Secret management systems Configuration files (outside version control)

Hardcoded Secrets Prevention Methods: How to Fix Your Code

The most effective way to fix hardcoded secrets is to externalize them from the code using environment variables or secure secret management systems.

Environment variables and secret managers provide a secure way to store and access sensitive credentials while keeping them separate from the application code.

Code Samples

Vulnerable Code

public class ApiClient {
    private static final String API_KEY = ;
    private static final String API_SECRET = "secretKey123!";
    
    public void makeApiCall() {
        // Use API_KEY and API_SECRET
    }
}

Fixed Code

public class ApiClient {
    private static final String API_KEY = System.getenv("API_KEY");
    private static final String API_SECRET = System.getenv("API_SECRET");
    
    public void makeApiCall() {
        if (API_KEY == null || API_SECRET == null) {
            throw new IllegalStateException("API credentials not configured");
        }
        // Use API_KEY and API_SECRET
    }
}

Fix Explanation

The vulnerable code contains hardcoded API credentials directly in the source code. The fix uses environment variables to retrieve sensitive credentials at runtime. Added null checks to ensure credentials are properly configured. Credentials can now be easily rotated without code changes.

Vulnerable Code

const config = {
    apiKey: 'abcdef123456',
    apiSecret: 'secretKey789!',
    endpoint: 'https://api.example.com'
};

axios.post(config.endpoint, data, {
    headers: { 'Authorization': config.apiKey }
});

Fixed Code

require('dotenv').config();

const config = {
    apiKey: process.env.API_KEY,
    apiSecret: process.env.API_SECRET,
    endpoint: process.env.API_ENDPOINT
};

if (!config.apiKey || !config.apiSecret) {
    throw new Error('Missing required API credentials');
}

axios.post(config.endpoint, data, {
    headers: { 'Authorization': config.apiKey }
});

Fix Explanation

The vulnerable code exposes API credentials directly in the source code. The fix uses dotenv to load environment variables. Credentials are accessed through process.env. Added validation to ensure required credentials are present.

Vulnerable Code

class DatabaseConnection:
    def __init__(self):
        self.username = "admin"
        self.password = "db_password123!"
        self.host = "database.example.com"
        
    def connect(self):
        return mysql.connector.connect(
            user=self.username,
            password=self.password,
            host=self.host
        )

Fixed Code

from os import environ
from dotenv import load_dotenv

class DatabaseConnection:
    def __init__(self):
        load_dotenv()
        self.username = environ.get('DB_USERNAME')
        self.password = environ.get('DB_PASSWORD')
        self.host = environ.get('DB_HOST')
        
    def connect(self):
        if not all([self.username, self.password, self.host]):
            raise ValueError("Missing database credentials")
        return mysql.connector.connect(
            user=self.username,
            password=self.password,
            host=self.host
        )

Fix Explanation

The vulnerable code contains hardcoded database credentials. The fix uses environment variables loaded through python-dotenv. Added validation to ensure all required credentials are available. Credentials can be managed separately from the code.

Vulnerable Code

public class PaymentService
{
    private readonly string apiKey = "pk_test_51ABC123";
    private readonly string apiSecret = "sk_test_98XYZ456";

    public async Task ProcessPayment(decimal amount)
    {
        var client = new HttpClient();
        client.DefaultRequestHeaders.Authorization = 
            new AuthenticationHeaderValue("Bearer", apiSecret);
        // Process payment
    }
}

Fixed Code

public class PaymentService
{
    private readonly string apiKey;
    private readonly string apiSecret;

    public PaymentService(IConfiguration configuration)
    {
        apiKey = configuration["Payment:ApiKey"] 
            ?? throw new ArgumentNullException("Payment:ApiKey");
        apiSecret = configuration["Payment:ApiSecret"]
            ?? throw new ArgumentNullException("Payment:ApiSecret");
    }

    public async Task ProcessPayment(decimal amount)
    {
        var client = new HttpClient();
        client.DefaultRequestHeaders.Authorization = 
            new AuthenticationHeaderValue("Bearer", apiSecret);
        // Process payment
    }
}

Fix Explanation

The vulnerable code contains hardcoded payment API credentials. The fix uses ASP.NET Core's configuration system. Credentials are injected through dependency injection. Added null checks to ensure credentials are configured.

Vulnerable Code

class S3Client
{
    private $accessKey = 'AKIAIOSFODNN7EXAMPLE';
    private $secretKey = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY';
    
    public function uploadFile($file)
    {
        $s3 = new Aws\S3\S3Client([
            'credentials' => [
                'key'    => $this->accessKey,
                'secret' => $this->secretKey,
            ],
            'region'  => 'us-west-2',
            'version' => 'latest'
        ]);
        // Upload file
    }
}

Fixed Code

class S3Client
{
    private $accessKey;
    private $secretKey;
    
    public function __construct()
    {
        $this->accessKey = getenv('AWS_ACCESS_KEY_ID');
        $this->secretKey = getenv('AWS_SECRET_ACCESS_KEY');
        
        if (!$this->accessKey || !$this->secretKey) {
            throw new RuntimeException('AWS credentials not configured');
        }
    }
    
    public function uploadFile($file)
    {
        $s3 = new Aws\S3\S3Client([
            'credentials' => [
                'key'    => $this->accessKey,
                'secret' => $this->secretKey,
            ],
            'region'  => 'us-west-2',
            'version' => 'latest'
        ]);
        // Upload file
    }
}

Fix Explanation

The vulnerable code contains hardcoded AWS credentials. The fix uses environment variables to store credentials. Added validation to ensure credentials are available. Follows AWS security best practices for credential management.

Vulnerable Code

class AuthService {
private:
    const std::string API_KEY = "my-static-api-key-123";
    const std::string API_SECRET = "my-static-secret-456";

public:
    bool authenticate() {
        // Use API_KEY and API_SECRET for authentication
        return true;
    }
};

Fixed Code

class AuthService {
private:
    std::string API_KEY;
    std::string API_SECRET;

public:
    AuthService() {
        char* apiKey = std::getenv("API_KEY");
        char* apiSecret = std::getenv("API_SECRET");
        
        if (!apiKey || !apiSecret) {
            throw std::runtime_error("Missing API credentials");
        }
        
        API_KEY = std::string(apiKey);
        API_SECRET = std::string(apiSecret);
    }

    bool authenticate() {
        // Use API_KEY and API_SECRET for authentication
        return true;
    }
};

Fix Explanation

The vulnerable code contains hardcoded API credentials. The fix uses environment variables through std::getenv. Added validation to ensure credentials are available. Credentials can be managed externally from the application.

Need more help in preventing Hardcoded Secrets?

We'd love your feedback!

We're excited to hear your thoughts and ideas about fixing vulnerabilities.

PreviousHardcoded Domain in HTMLNextHTTP Response Splitting Attacks

Last updated 2 months ago

Was this helpful?

supports fixing many forms of Hardcoded Secrets vulnerabilities, and can mitigate your issues in batch.

Start now for free at

or if you have any corrections, questions or suggestions. Start now for free at https://app.mobb.ai

Mobb
app.mobb.ai
Book a meeting
Contact us