Code Security Sanitizer Formatter🔒 100% local
Audit for secrets. Privacy-first, no server uploads, no tracking.
Scans pasted code line by line against 17 rules for known-unsafe constructs - eval and the Function constructor, innerHTML assignment, document.write, shell execution, SQL built by concatenation, hard-coded secrets, prototype pollution, wildcard CORS, disabled TLS verification, weak ciphers and more - then deducts 40 points per critical finding, 20 per high, 8 per medium and 3 per low from a starting score of 100. Each hit is reported with its line number, the reason and a concrete fix, grouped by severity. One finding per line is kept so a single bad line does not drown the report.
How to use it
- Paste the function, file or diff you want checked.
- Press Process.
- Read the score and grade, then clear the CRITICAL and HIGH blocks before looking at anything in medium.
Worked example
eval("alert(1)")
document.write(name)becomesSecurity score: 40/100 (grade D)
Findings: 2 — 1 critical, 1 high, 0 medium, 0 low
Analysed: 2 lines, 37 chars
CRITICAL (1)
line 1 eval() executes arbitrary strings as code
→ Replace with JSON.parse for data, or a lookup map for branching.
eval("alert(1)")
HIGH (1)
line 2 document.write can inject markup and blocks parsing
→ Build DOM nodes with createElement/append.
document.write(name)
Priority: fix every CRITICAL and HIGH before this code ships. They are all remotely exploitable given the right input.
Limits of a pattern scan:
• It cannot see data flow (whether the tainted value really reaches the sink).
• It cannot audit dependencies — run npm audit / pip-audit for that.
• Add a real SAST tool (CodeQL, Semgrep) to CI for depth.A critical (40 points) and a high (20 points) leave a score of 40, which grades as D. The rule ids are not shown; each block gives the line, the reason, the fix and the matched line.
When to use it
- An early smell check on a snippet before it goes into a pull request.
- Reading code you did not write - a vendor drop, a generated file, a snippet from a tutorial.
- Showing a teammate which constructs get flagged, and what to write instead.
What it does not do
- It is a pattern scan with no data-flow analysis, so a clean report is not proof of safety: it cannot tell whether a tainted value actually reaches the sink.
- Dependency vulnerabilities are out of scope; run npm audit or pip-audit for those.
- Reformatting defeats the regexes - a secret split over two lines, or a query assembled by a helper, will not match the rule.
- Scanning is line-based and stops at the first matching rule per line, so a line with two problems reports only the more urgent one.