MoreOnlineTools
ESC

Security Audit Kit

A 7-step workflow to harden your application's security posture

Security Audit Kit

This workflow is for developers and sysadmins who want to audit and improve the security of a web application or server environment. Follow the steps in order to cover credential hygiene, data protection, and HTTP security headers. By the end, you will have addressed the most common attack vectors — weak passwords, plaintext storage, unencrypted data, and misconfigured browser policies.

7 steps ~20 min 7 tools
01

Generate Strong Credentials

Weak passwords are the leading cause of security breaches. Generate cryptographically random passwords for all service accounts, API keys, and admin credentials.

Password Generator
Generate a cryptographically random password of at least 16 characters with uppercase, lowercase, numbers, and symbols.
Open Tool
02

Test Existing Passwords

Before trusting an existing password, evaluate it against entropy calculations and common pattern detection. Anything below 70 bits of entropy should be replaced.

Password Strength Checker
Paste each existing password here to measure its entropy score and check for predictable patterns or dictionary words.
Open Tool
03

Hash Passwords for Storage

Never store plaintext passwords. Bcrypt adds an automatic salt and is deliberately slow — each hash takes milliseconds for you but makes brute-force attacks prohibitively expensive.

Bcrypt Generator
Enter a password and generate a bcrypt hash at an appropriate cost factor (12 recommended) to store in your database.
Open Tool
04

Hash Data for Integrity

Verify file integrity, create checksums for deployments, or generate deterministic identifiers. SHA-256 is the standard for checksums in security contexts.

SHA-256 Generator
Hash deployment artifacts, config files, or any data to create a checksum you can verify after transfer or storage.
Open Tool
05

Encrypt Sensitive Data

For data that needs to be recovered later (unlike hashes), AES-256 is the industry standard. Use it for encrypting tokens, config values, or any data stored outside your application.

AES Encryption
Encrypt API tokens, secret keys, or configuration values using AES-256 so they can be safely stored or transmitted.
Open Tool
06

Write Content Security Policy

CSP headers prevent XSS attacks by controlling what resources browsers can load. A well-configured CSP is one of the most effective defenses against script injection.

CSP Generator
Build a Content-Security-Policy header by selecting the sources your application actually uses, then copy the header value into your server config.
Open Tool
07

Configure CORS Headers

Misconfigured CORS is a common API vulnerability. Generate precise headers to allow only intended origins — a wildcard (*) on a credentialed endpoint is a critical security flaw.

CORS Header Generator
Specify your allowed origins, methods, and headers to generate the exact Access-Control-* header values your API needs.
Open Tool

Pro Tips

  • Rotate credentials after every audit. Even a strong password becomes a liability if it has been in use for a year or more without rotation.
  • Use a cost factor of 12 or higher for bcrypt in production. On modern hardware, cost 10 can be cracked faster than you expect as computing power grows.
  • Test your CSP in report-only mode first (Content-Security-Policy-Report-Only) before enforcing it — a misconfigured policy can break your entire application.

Frequently Asked Questions

Hashing is a one-way process: you cannot reverse a hash back to the original data. It is used to verify integrity or store passwords. Encryption is two-way: data can be decrypted with the correct key. Use hashing for passwords and checksums; use encryption for data you need to retrieve later.

At minimum 16 characters for human-typed passwords, and 32+ characters for machine-generated credentials like API keys. Length contributes more to entropy than character variety alone — a 20-character lowercase string is stronger than a 10-character mixed string.

Bcrypt is far better for password storage. SHA-256 is designed to be fast, which makes it easy to brute-force. Bcrypt is intentionally slow and includes a built-in salt, making it the right choice for storing user passwords. SHA-256 is appropriate for checksums and data integrity, not credential storage.

No, CSP significantly reduces the risk and impact of XSS but does not eliminate it entirely. A poorly written CSP with overly broad rules (like unsafe-inline) provides little protection. CSP works best as one layer in a defence-in-depth approach alongside input sanitization and output encoding.

No. Every tool on this site runs entirely in your browser. Your passwords, keys, and data never leave your device — nothing is sent to any server. You can verify this by disconnecting from the internet and using the tools; they will continue to work.

Безопасность и конфиденциальность

Безопасность ваших данных — наш приоритет

Локальная обработка

Вся обработка происходит в вашем браузере

Без передачи данных

Ваши данные не отправляются на наши серверы

Без хранения данных

Данные не хранятся и не передаются

SSL-шифрование

SSL-шифрование для безопасного соединения