DevOps 2026-03-09

Pre-Deploy Security: Hash Assets → Encode Config → Rotate Passwords

Security checklist before every deployment: hash static assets for integrity verification, encode configuration secrets for safe storage, and generate fresh credentials. Ship securely every time.

The Problem

Every deployment is a security event. Static assets can be tampered with in CDNs. Config values can be accidentally committed in plaintext. Default credentials sometimes ship to production. A 3-step pre-deployment security check catches these before users are affected.

Why This Matters

Security incidents often trace back to skipped pre-deployment checks. File integrity hashes catch CDN or supply chain tampering. Encoded secrets prevent accidental credential exposure. Fresh passwords limit the blast radius of credential leaks. Each step takes under 60 seconds.

Step-by-Step Instructions

1

Hash critical static assets

For JavaScript and CSS files deployed to a CDN, compute SHA-256 with the Hash Generator. Add the hash to your HTML as a Subresource Integrity (SRI) attribute: integrity="sha256-[hash]". Browsers will refuse to execute tampered files.

2

Encode all secrets for config storage

Review your .env and CI/CD variables. Any secret with special characters should be Base64-encoded using the Base64 Encoder before storage. This prevents shell escaping issues and makes values safe for all deployment platforms.

3

Generate fresh credentials if rotating

If this deployment includes a credential rotation, use the Password Generator to create cryptographically strong replacements (32+ characters). Update all dependent services before deploying — never ship with the old credentials still active.

Try It Now — Hash Generator

Open full page →
Hash Generator — Live Demo

All processing happens in your browser — no data is sent to any server.

Before & After Example

Typical deployment without security checks
# Deploying v2.3.1

# assets/app.js → CDN (no integrity check)
# .env: DB_PASS=same-password-since-2024
# CI var: API_KEY=hello world (has space!)

# Risks:
# - CDN compromise undetected
# - Stale credentials
# - Config parsing errors in prod
Deployment with security checklist applied
# Deploying v2.3.1 ✓

# assets/app.js integrity="sha256-abc123..." crossorigin="anonymous"
# .env: DB_PASS=kX8mP2vQ9nR4sT7wY1zA3bC (rotated, 32 chars)
# CI var: API_KEY=aGVsbG8gd29ybGQ=  (Base64-encoded, no space issues)

# ✓ Tampering detection enabled
# ✓ Fresh credentials deployed
# ✓ Config encoding verified

Frequently Asked Questions

What is Subresource Integrity (SRI) and should I use it?

SRI is a browser security feature that verifies CDN-hosted files haven't been tampered with. Add integrity="sha256-[hash]" crossorigin="anonymous" to your <script> and <link> tags. Essential if you load third-party scripts from a CDN.

How do I check if my .env has been accidentally committed?

Run git log --all --full-history -- .env to see if .env was ever committed. Use git secret or truffleHog to scan your entire history for secrets. If found, rotate the exposed credentials immediately — removing from history doesn't invalidate the leak.

What's the minimum deployment security checklist?

1) No default/weak credentials. 2) No secrets in environment variables without encoding. 3) HTTPS everywhere. 4) SRI for CDN assets. 5) Security headers (CSP, HSTS, X-Frame-Options). 6) Dependencies updated (no known CVEs). These six checks prevent the majority of common security incidents.

Related Workflows

Try all 3 tools in this workflow

Each tool is free, runs in your browser, and requires no signup.

Related Workflow Guides