Website Security Review Guide
How DataJelly Automatically Detects Vulnerabilities in Your HTML, Headers, Scripts, and Snapshot Data
Modern web security requires more than HTTPS and strong passwords. Attackers look for misconfigurations, leaked secrets, unprotected admin routes, unsafe scripts, and weak security headers — all of which can be unintentionally exposed inside a website's rendered HTML.
DataJelly's Security Review System performs a deep, automated security audit every time your site is snapshotted. This guide explains what we test, why each test matters, and how the findings help secure your production environment.
Why a Security Review Matters
Most security vulnerabilities today are introduced in the frontend, not the backend:
These exposures often go unnoticed because they appear in the rendered website, not the source code.
DataJelly detects exactly what attackers can see.
How the Security Review Works
For every page snapshot, DataJelly analyzes:
1. Rendered HTML (SSR snapshot or live fetch)
We examine the full HTML output generated by your SPA or website.
2. Response Headers
CSP, HSTS, CORS, cookies, server identifiers, referrer policy, and more.
3. JavaScript Script Contents
We scan all <script> tags and downloaded JS files for secrets and unsafe patterns.
4. Browser Console Logs
Errors and warnings captured during snapshot rendering.
5. Exposed Files & Directory Access
We directly test whether .env, .git, backups, configs, or admin directories are accessible.
Together, these layers provide a near-pentest-quality review of your site, without requiring server access or credentials.
Security Tests Performed (Complete Breakdown)
All sections map directly to logic in SecurityReviewService
1. Critical Security Headers
Security starts with correct response headers. DataJelly checks:
Content Security Policy (CSP)
- •Missing CSP
- •CSP with unsafe-inline or unsafe-eval
- •CSP allowing wildcard script sources (script-src *)
Why it matters: Prevents XSS, script injection, and supply-chain attacks.
Strict-Transport-Security (HSTS)
Missing HSTS header
Prevents: SSL stripping attacks
X-Frame-Options
Missing or insecure values
Prevents: Clickjacking
Server Identifier Exposure
We detect sensitive headers like:
- •
Server - •
X-AspNet-Version - •
X-Generator - •
X-Powered-By
Why it matters: Avoids giving attackers framework/version intel.
2. Cookie Security and Hardening
We analyze every Set-Cookie header for:
- Missing Secure
- Missing HttpOnly
- Missing SameSite
- Session cookies without flags
- SameSite=None without Secure
- Long-lived cookies (>30 days)
Cookies represent session identity. Misconfiguration = session hijacking.
3. Secret & Token Exposure
We scan HTML, inline JS, and external JS for:
These are some of the most catastrophic leaks — often exploited within hours.
4. Admin, Debug, and Sensitive Route Exposure
We detect exposed routes like:
/admin/debug/users/auth/dev/api/users/dashboard/auth/bypassWe also test whether admin directories return real content.
Attackers routinely scan for these endpoints.
5. Insecure Script Loading & CDN Risks
We flag:
- External scripts without Subresource Integrity (SRI)
- Scripts loaded over HTTP
- Scripts loaded from known risky CDNs
- Source maps publicly referenced
Prevents supply-chain attacks and unauthorized script changes.
6. Console Errors and Stack Trace Exposure
We analyze captured console logs for:
- •Stack traces
- •Runtime errors
- •Internal file paths
- •API endpoints
- •Developer debug output
We also scan HTML for stack traces, .NET exceptions, Python/Django errors, and PHP/Laravel traces.
Stack traces leak internal architecture and error handling.
7. Sensitive File Exposure & Directory Access
We check whether critical files are publicly accessible:
.env Files
We probe: /.env, /.env.local, /.env.production, and more
.git Folder
Testing: /.git/HEAD
Backup / Dump Files
/backup.sql, /dump.sql, /config.zip, etc.
These files cripple security when exposed.
Additional Security Tests
Cloud Resource Exposure
AWS S3, GCP, Azure Portal links, GitHub admin pages
HTML & Form Security
Insecure action URLs, missing CSRF tokens, autocomplete issues
Inline JavaScript Review
Secrets, unsafe eval, DOM XSS sinks, debug flags
DOM Attack Surfaces
Inline event handlers, unsecured iframes, meta refresh redirects
Link-Level Security
Open redirect patterns, sensitive file links, admin UI links
Comments & Source Disclosure
Secrets in HTML comments, internal URLs, hardcoded credentials
security.txt Verification
Checks for /.well-known/security.txt disclosure policy
Final Deduplication
Severity ranking (critical/warning/info), clean output
Why Our Security Review Is Different
1. Snapshot-aware
We test what search engines and attackers actually see, not your local dev build.
2. Multi-layer scanning
Headers + HTML + JS + DOM + filesystem probes + cloud patterns.
3. SPA-friendly
Most scanners fail on SPAs. DataJelly snapshots bypass JS issues completely.
4. Real browser behaviors
Admin directory tests use a real browser UA to avoid bot blocks.
5. Security-first heuristics
Our patterns come from real-world exploit techniques, not static rules.
Conclusion: Defense Starts with Visibility
Websites often unknowingly leak:
DataJelly's Security Review exposes these blind spots using the same methods attackers use — giving you a clear, actionable roadmap to fix vulnerabilities before they become incidents.
Your site deserves to be fast, visible, and secure.
DataJelly makes that possible.
Start Your Security Review
Comprehensive security scanning for your snapshots and production site
Get Started Free