Web Pentest & Security Assessment – Complete Guide to Safe Website Exposure Checks

Most website compromises do not start with a clever exploit. They start with a forgotten .env file, a deployed .git directory, a backup archive in the web root, a phpMyAdmin login nobody remembers installing, or a missing header that turns a small bug into an XSS problem. These are cheap to find from the outside, which is exactly why attackers look for them first, and why owners should look first.

Web Pentest & Security Assessment checks a website you own or are authorized to test for these publicly visible weaknesses: technologies and versions, security headers, cookie flags, CORS, TLS, exposed and default files, admin and API endpoints. It reports findings with evidence, severity and a fix, plus a transparent exposure score. It does not exploit anything.

What is a website exposure assessment?

In simple terms

An exposure assessment looks at a website the way an outsider can see it: what the server says about itself in its responses, how its encryption is configured, and whether files that should be private can be downloaded. It reports what it finds and what to change. Unlike a penetration test, it never tries to break in, log in or change anything.

Technical background

The checks map to well-documented web security controls:

• Response headers. Content-Security-Policy restricts where scripts may load from; Strict-Transport-Security (HSTS, RFC 6797) tells browsers to use HTTPS only; X-Content-Type-Options: nosniff, X-Frame-Options or CSP frame-ancestors (clickjacking), Referrer-Policy, Permissions-Policy and the cross-origin isolation headers COOP, CORP and COEP. Version banners in Server and X-Powered-By are information disclosure.
• Cookies. Secure, HttpOnly and SameSite attributes (RFC 6265) protect session cookies against interception, script access and cross-site sending.
• CORS. A server that reflects an arbitrary Origin in Access-Control-Allow-Origin together with Access-Control-Allow-Credentials: true lets any site read authenticated responses. See MDN on CORS.
• TLS. Certificate trust, hostname match, expiry, negotiated protocol version (TLS 1.0/1.1 are deprecated by RFC 8996) and an HTTP-to-HTTPS redirect.
• Exposed files and endpoints. Version-control metadata (.git/config, .svn/entries), environment and configuration files, database dumps, backup archives, private keys, logs, default installation pages, admin consoles and API documentation endpoints.
• Outdated components. Version strings visible in headers, generator tags or asset paths, compared against fixed, documented end-of-life or vulnerability boundaries.

Why use the security assessment?

• Find leaks before attackers do. Exposed .env, .git, SQL dumps and backups are found by automated scanners within days of deployment.
• Verify hardening after changes. After a web server migration, CDN change or CMS update, check that headers, HSTS, redirects and cookie flags survived.
• Get prioritized, fixable output. Each finding includes why it matters, the evidence and a concrete recommendation.
• Document a baseline. Export the report as CSV or JSON, or print it, for change tickets and audits.

Who should use it?

• Website owners and administrators responsible for their own sites.
• DevOps and platform teams checking deployments and staging environments they control.
• Agencies and freelancers assessing client sites with written authorization.
• Security teams doing quick external checks of their organization's web properties.

It is not for testing sites you do not own or are not authorized to test.

How the security assessment works

Every step is a separate request to the NetTools.tech API, so the page shows real progress. All requests come from the NetTools server with the user agent NetToolsBot/1.0, are GET requests only, and are restricted to the host you entered. Private, internal and loopback addresses are refused (SSRF protection), and redirects to other hosts are not followed; a redirect between example.com and www.example.com is treated as the same site.

Quick checks (no verification needed, consent checkbox required):

1. Technology detection & headers. One GET of the page, following up to five same-site redirects and reading at most 512 KB. The request carries an Origin: https://cors-check.nettools.tech header to test whether CORS reflects foreign origins. The server reads response headers, cookie names and flags (not values), the generator meta tag, script and stylesheet paths and a few page markers: source-map references, stack traces or debug output, and "Index of /" directory listings. Technologies are identified from these public indicators with a confidence level.
2. TLS / HTTPS. A TLS handshake on port 443 (certificate trust, hostname match, days to expiry, issuer, protocol and cipher) and a request to http:// to see whether it redirects to HTTPS.
3. Well-known files. /robots.txt, /sitemap.xml and /.well-known/security.txt.

Wordlist checks (ownership verification required): 101 curated paths in groups (common files, common directories, sensitive files, default/installation artifacts, admin & login interfaces, API endpoints, and CMS-specific checks for WordPress, Joomla, Drupal, Magento and others, run only for a CMS that was actually detected). Before probing, the server requests a random non-existent path to learn the site's "not found" response (soft-404 baseline). Each path is then requested sequentially at the rate you chose (1–5 requests per second), at most 20 paths per API call, reading at most 64 KB. A hit counts as found only if the content matches the expected signature for that file; contents are never returned to your browser. The scan stops after five consecutive failures, and each target host has a budget of 400 requests per hour.

Ownership verification. Press Get verification record to receive a TXT record name (_nettools-verify.<host>) and value (nettools-verify=<token>). The token is computed with a server secret for that domain and is valid for the current and previous week. Publish it at your DNS provider and press Check verification. The server looks for it at the host and up to three parent levels, so a record for the registered domain (request the token by entering the bare domain) covers its subdomains. Successful verification is cached for ten minutes. The same mechanism verifies targets for the Port Scanner.

How to use the NetTools.tech security assessment

1. Open Web Pentest & Security Assessment.
2. Enter the Website URL, e.g. https://www.example.com. The hint below shows the scope (the origin only).
3. Optional: press Get verification record, add the TXT record at your DNS provider, wait a few minutes, then press Check verification until the badge says "Ownership verified".
4. Choose a Profile: Quick (technologies, headers, TLS and well-known files, about eight requests), Standard (Quick plus all wordlist groups if verified), or Custom to tick individual Modules. Modules marked "verified only" stay disabled until verification succeeds.
5. Choose the Request rate (1, 2, 3 or 5 requests per second; 3 is the default).
6. Tick I own this website or have explicit written authorization to test it.
7. Press Start assessment. Watch Scan progress; Stop aborts the scan.
8. Review the report and export it with CSV, JSON, Copy all or Print.

Understanding the results

Example: a quick check that finds weak headers

Running the Quick profile against https://www.example.com (illustrative values) produces:

Exposure score: 33 / 100 · Medium exposure
Findings:
  Medium  Content-Security-Policy missing
  Medium  Strict-Transport-Security missing
  Medium  Cookie "sessionid" lacks Secure, HttpOnly
  Low     X-Content-Type-Options missing
  Low     Server weak                              (Server: nginx/1.18.0)
  Low     Software versions are publicly visible   (Nginx 1.18.0)
TLS: HTTPS available · Certificate trusted · Hostname matches · 61 days left · HTTP → HTTPS redirect
Paths: /robots.txt Found · /sitemap.xml Not found · /.well-known/security.txt Not found

The score is three Medium findings (3 × 8 = 24) plus three Low findings (3 × 3 = 9) = 33, which falls in the Medium band (25–49). Fixes: add CSP and HSTS headers, set Secure; HttpOnly; SameSite=Lax on the session cookie, add nosniff, hide the version (server_tokens off), and publish a security.txt. After verification, a Standard scan would additionally show whether files such as /.env or /.git/config are reachable.

Common use cases

• Post-deployment check that a new site or staging copy does not expose .git, .env or backups.
• Validating security headers after moving behind a CDN or reverse proxy.
• Reviewing a CMS installation for default files, install scripts and exposed admin pages.
• Producing a short, exportable report for a client or change ticket.
• Re-testing after fixes to confirm findings are gone.

Troubleshooting

"Verified only" modules stay disabled

Verification failed or has not been checked. Make sure the TXT record name is exactly _nettools-verify.<host> (or the parent domain, using a token requested for that domain), the value is the full nettools-verify=… string, and DNS has propagated. Tokens expire after one to two weeks; request a new one if needed.

"The target could not be reached"

The site did not answer within the time limit, refused the connection, or resolves to a private or internal address, which is blocked. Check the URL with HTTP Status Checker.

The scan stopped with "The target stopped answering"

Five requests in a row failed or timed out, often because a WAF or rate limiter started blocking. Allow the scan rate, lower it to 1 request per second, or test later.

"This website has reached its hourly request budget"

Each target host has a limit of 400 requests per hour across all scans. Wait and run again.

Fingerprint stopped at a redirect

The page redirects to a different host (for example a separate login domain). Scan that host separately if you are authorized for it.

Many paths show "Possible"

The site answers 200 for paths whose content does not match the expected format. Usually that is a catch-all route; open the path yourself to confirm.

Common mistakes

• Scanning a site you are not authorized to test. Ticking the consent box is a legal statement, not a formality.
• Treating a low score as a clean bill of health. Absence of findings only means none of these checks found something.
• Ignoring "Possible" results for critical files instead of verifying them manually.
• Fixing headers in the application while a CDN or proxy strips or overrides them; re-scan after every change.
• Leaving the verification TXT record in DNS after testing; remove it when done.

Limitations

• It is not a penetration test: no exploitation, authentication, form submission, fuzzing, injection testing or business-logic review.
• Only one host per scan; other subdomains, APIs on other hosts and redirected login domains are out of scope.
• Wordlists are curated and small (101 paths); custom file names and paths outside the lists are not found.
• Technology detection relies on public indicators; hidden or customized stacks show fewer technologies, and versions may be undeterminable.
• Version checks use a short list of fixed boundaries, not a full CVE database.
• WAFs and rate limiting can block requests and make results incomplete.
• TLS checks cover the negotiated connection and certificate; for full chain details use the SSL Checker.
• The terminal /pentest command is disabled; the assessment runs only from the web page.

Security & privacy

The URL you enter is sent to the NetTools server, which makes all requests to the target itself; the target sees the NetTools server and the NetToolsBot/1.0 user agent, never your IP address. The verification token is computed with a secret key and not stored; scan results are not kept on the server, as stated in the privacy policy. For path checks, only status code, size, content type and signature match are returned, never file contents. The tool never asks for, sends or tries credentials. Do not enter URLs containing tokens, passwords or session parameters; URLs with embedded credentials are rejected.

Related tools

• SSL Checker – full certificate chain and expiry details. Guide: SSL Certificate Checker guide.
• Port Scanner & Firewall Test – open ports on verified targets. Guide: Port Scanner guide.
• security.txt Checker – validate your vulnerability disclosure contact. Guide: security.txt guide.
• Robots.txt Checker – review what your robots.txt reveals and allows. Guide: Robots.txt guide.
• HTTP Status Checker – check responses and redirects. Guide: HTTP Status guide.
• Overview: Security & Testing tools.

Summary

The NetTools security assessment checks a website you are authorized to test for publicly visible weaknesses: headers, cookies, CORS, TLS, technologies and versions, and, after DNS TXT ownership verification, a curated list of sensitive, default, admin and API paths. It sends only GET requests at a gentle, budgeted rate, confirms file hits by content, never downloads sensitive contents and never exploits anything. Use it as a regular hygiene check, not as a substitute for a professional penetration test.