# A 20-Minute Website Security Triage: Which Vulnify Tools to Run, in What Order, and What Each Result Means

Canonical: https://vulnify.app/blog/20-minute-website-security-triage-vulnify-tools

Use Vulnify's free tools in a deliberate 20-minute sequence to check TLS, headers, CSP, DNS, email, exposed paths, libraries, redirects, subdomains, and compromise signals.

You do not always need a full penetration test to answer the first security question about a website: what should I look at first? A short triage can establish whether the public site has obvious problems with TLS, headers, DNS, email authentication, exposed paths, subdomains, redirects, client-side libraries, or compromise signals. Vulnify's Tools page includes a Run All Tools on One Domain option that runs the free checks in one pass and produces a consolidated report. That is the fastest starting point. The workflow below explains how to interpret the results and where a focused tool or full vulnerability scan becomes the better next step. Minute 0: confirm the target and authorization Use the workflow only on a site you own or are authorized to assess. Confirm the canonical production hostname. If example.com redirects to www.example.com , note both but treat the live application destination as the main target. If the business also uses app , shop , or api hostnames, those are separate public surfaces and may need their own checks. Minutes 1 to 5: run all free tools on the domain Start on the Vulnify Tools page and use Run All Tools on One Domain. The purpose is breadth. You want a consolidated view before diving into any single warning. Do not treat the combined report as a vulnerability scan. The free tools are focused public checks. A full scan covers a broader set of vulnerability tests and requires a verified account. Read TLS and certificate results first If HTTPS is invalid, expired, misconfigured, or serving the wrong certificate, fix that before lower-priority hardening. Users must be able to establish a trusted encrypted connection. Check certificate validity, hostname coverage, expiry, chain trust, and protocol posture. If the SSL Checker raises a concern, open the focused SSL or TLS Deep Analysis result for more detail. Then read security headers Security headers are often quick to classify: HSTS: relevant once HTTPS is working correctly. CSP: reduces the impact of script injection when designed properly. frame controls: reduce clickjacking exposure. Referrer-Policy: controls referrer data leakage. Permissions-Policy: constrains selected browser capabilities. A missing header is not automatically the most urgent issue on the site. Prioritize according to what the site does and whether a stronger underlying vulnerability exists. Review CSP separately if present If the site has Content Security Policy, use the CSP Checker to inspect whether it is narrow or overly permissive. Look for broad wildcards, unnecessary origins, 'unsafe-inline' , and 'unsafe-eval' . Do not paste a strict replacement into production without testing. CSP should normally be staged in Report-Only mode when significant changes are required. Check DNS and email authentication A website domain is also an email and DNS asset. Review public DNS records and the Email Security Checker results for SPF, DKIM, and DMARC posture. If the business does not send email from the domain, that does not make spoofing irrelevant. A deliberate mail policy can still protect the brand. If it does send email, authentication records must match the real sender inventory. Check exposed paths Use Exposed Paths Checker to look for publicly reachable paths that commonly reveal configuration, backups, source-control metadata, administrative interfaces, or deployment artifacts. A response deserves validation. A route returning HTTP 200 may be a custom error page rather than a real exposed file. Read the evidence before escalating. Check technology and JavaScript library signals Technology Fingerprint can help identify visible platform clues. The JS Library Vulnerability Checker can flag supported public library/version evidence and outdated-component risk. These are external observations. They do not replace repository-level dependency scanning because private server packages and bundled transitive dependencies may leave no public fingerprint. Check redirects and mixed content Redirect Chain Checker can expose unnecessary hops, unexpected destinations, or HTTP-to-HTTPS behavior. Mixed Content Checker is useful when an HTTPS page still requests insecure resources. Unexpected external redirects deserve investigation because they can indicate configuration errors, compromise, or an unsafe redirect mechanism. Understand the public edge WAF / CDN Detector can help identify the public edge infrastructure. This matters when headers, TLS, redirects, or caching differ between the origin and what visitors see. Do not assume a CDN means a WAF is actively protecting every route or that a detected WAF configuration is sufficient. It is context for the assessment. Check subdomains when the site matters to the business Passive Subdomain Discovery can reveal public candidates such as staging, API, support, and old service names. For each candidate, decide whether it is active, owned, required, and secured. If a subdomain points to an external service that may have been deleted, use the Subdomain Takeover Scanner to review takeover indicators. Check compromise signals when behavior is strange If users report browser warnings, suspicious redirects, hidden content, or unexpected mining behavior, run Site Compromise Checker. It is designed for public signals such as Safe Browsing status, redirect behavior, hidden frames, meta refreshes, and known miner hosts. A clean result does not prove the server is malware-free. Server-side investigation may still be required. Decide whether to escalate to a full vulnerability scan Use a full Vulnify scan when you need broader testing beyond focused configuration checks. This is particularly appropriate after launch, after significant application changes, when the site accepts user input, or when the free tools expose enough issues that a broader assessment is justified. Choose scan depth according to the authorized target and the level of testing you need. Do not run aggressive active testing against systems you do not own or have permission to assess. How to prioritize what you find Use a simple order: active compromise or unsafe redirect behavior; exposed sensitive files or administrative surfaces; high-confidence injection or access-control findings from a full scan; broken TLS or certificate trust; critical authentication and session weaknesses; high-impact outdated components; security-header and policy hardening; lower-risk informational findings. Severity labels are useful, but business context matters. An exposed backup containing credentials is more urgent than a cosmetic missing header. Record before-and-after evidence For each issue, save the affected URL, observed result, date, and planned remediation. After the fix is deployed, rerun the same focused tool or scan condition. The objective is not to make a dashboard green. It is to prove the public behavior changed. What a 20-minute triage cannot prove A short public review cannot prove secure authorization, tenant isolation, business logic, code quality, infrastructure hardening, secrets management, or every authenticated workflow. It is a first-pass assessment. If the site handles payments, sensitive customer data, healthcare information, administrator workflows, or valuable accounts, plan deeper testing. The 20-minute triage order 1. Confirm target and authorization 2. Run All Tools on One Domain 3. Read SSL/TLS 4. Read security headers and CSP 5. Review DNS and email authentication 6. Check exposed paths 7. Review technology and JS libraries 8. Check redirects and mixed content 9. Review WAF/CDN context 10. Discover subdomains 11. Check compromise signals when relevant 12. Escalate to a full scan when needed 13. Fix highest-impact issues 14. Retest the public result When a focused tool is better than another full scan If the only change was a certificate renewal, rerunning SSL Checker or TLS Deep Analysis is faster and easier to interpret than repeating an unrelated broad scan. If you changed CSP, use CSP Checker and Security Headers Analyzer first. If you changed DNS email records, use DNS Record Lookup and Email Security Checker. Focused retesting keeps the evidence close to the remediation. A full scan still makes sense after broader application or infrastructure changes. Turn the triage into a maintenance routine Save the consolidated report date and the important results. Repeat the workflow after major releases, hosting changes, domain migrations, new third-party scripts, or security incidents. A short repeated process is more valuable than a detailed one-time review that nobody runs again. For higher-value sites, combine this public triage with scheduled scans and internal controls such as dependency scanning, access review, backups, and application-specific security tests. Know when to stop triage and investigate If you see an exposed credential file, active malware warning, unexpected external redirect, severe certificate problem, or high-confidence vulnerability, stop treating the work as routine triage. Preserve evidence, contain the issue as appropriate, and investigate the underlying cause. The 20-minute workflow is designed to find the next question quickly. It is not a reason to rush through a real incident. Keep a small evidence log For recurring triage, record the date, target hostname, major findings, and the tool used to verify each fix. This makes future comparisons practical and prevents the same low-priority warning from being rediscovered as if it were new every month. Why this order works The sequence moves from foundational transport and configuration into broader exposure. It gives you enough context to avoid spending the first twenty minutes chasing one low-value warning while an expired certificate, exposed backup, suspicious redirect, or forgotten staging host is sitting in plain sight. It also creates a repeatable baseline. Run the same triage after major releases, hosting changes, DNS migrations, or security fixes and compare what changed.