Certificates, security headers, exposed services, DNS and email, leaked files: what an outside scan shows, and how to check yours.
What an outside scan reveals about a terminal
Before anyone logs in, a terminal's website, portal and mail domain already tell a stranger a great deal. This page, for the IT managers, CIOs and webmasters who run those sites, is the same list an outside scan works through: what an attacker sees, why it matters, and how to check it on your own names with free tools. It names no terminal and no client, and it is for self-checking a site you own and are authorised to test.
Certificates and TLS
Security headers
Exposed services and ports
DNS and email authentication
Leaked information
Watching and responding
Six families of checks
The 24 checks come from the TLS specification (RFC 8446) and NIST SP 800-52 Rev. 2, the HSTS and security-header standards (RFC 6797, the OWASP Secure Headers Project), the email-authentication RFCs (SPF, DKIM, DMARC and MTA-STS), RFC 9116 for security.txt, CISA's email and web directive and its Stuff Off Search guidance, the NSA and CISA top ten misconfigurations, the US Coast Guard cyber rule (33 CFR 101.650), the IMO cyber guidelines and NIS2 Article 21. Open a check below for what to ask from outside, why, and what a passing result looks like.
T · Certificates and TLS · 4 checks
H · Security headers · 5 checks
S · Exposed services and ports · 3 checks
D · DNS and email authentication · 5 checks
L · Leaked information · 4 checks
W · Watching and responding · 3 checks
The 24 checks and what a pass looks like
Click a check to read what to look for from the outside, why it matters, and what a passing result looks like.
Check from outside
Does every name you serve over HTTPS (the apex, www, the portal, the staff login, every live subdomain) present a certificate that matches the name, is inside its validity dates, and chains to a trusted root with its intermediate certificates sent?
Why
A name mismatch, a missing intermediate or an untrusted root makes the browser warn the visitor, and users learn to click through warnings, which is exactly what an attacker wants. NIST SP 800-52 Rev. 2 (section 3) requires server certificates that validate to a trusted root. The first thing an outside scan reports is which of your names fail.
A passing result
- The certificate for each name, read in the browser (the padlock) or by a free TLS test site
- That the chain is complete, with the intermediate certificates served, not only the leaf
Sources: NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of TLS Implementations (August 2019) · IETF, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018)
Check from outside
For each certificate, how many days are left, who is alerted before it expires, and does renewal happen automatically or by a person who might be on leave?
Why
An expired certificate is the most common visible failure of a site, and it takes a public portal down for every haulier and partner at once. Certificates are public: anyone, including an attacker planning the day of maximum disruption, can read your expiry dates in the certificate transparency logs.
A passing result
- The expiry date of each certificate and the number of days left today
- Who or what renews it, and the alert that fires before the last week
Check from outside
Does the site accept only TLS 1.2 and TLS 1.3, with SSL 3.0, TLS 1.0 and TLS 1.1 and the weak ciphers turned off?
Why
NIST SP 800-52 Rev. 2 requires TLS 1.2 at least and recommends TLS 1.3, and the old versions carry known attacks. A free TLS test site grades this from the outside in a minute and names each weak cipher still offered.
A passing result
- The list of protocol versions the server accepts, from a free TLS test
- That SSL 3.0, TLS 1.0 and TLS 1.1 are refused, and no cipher is flagged weak
Sources: NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of TLS Implementations (August 2019) · IETF, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018)
Check from outside
Does a request to the plain-HTTP address (port 80) redirect to HTTPS, and does the HTTPS response carry a Strict-Transport-Security header with a long max-age?
Why
Without the redirect and HSTS, a visitor's first request can be downgraded to plain HTTP and read or changed on the way. RFC 6797 defines HSTS for exactly this; CISA BOD 18-01 required federal sites to enforce HTTPS and HSTS. Both the redirect and the header are visible from the outside with no login.
A passing result
- That http:// redirects to https:// for each name
- The Strict-Transport-Security header and its max-age on the HTTPS response
Sources: IETF, RFC 6797, HTTP Strict Transport Security (HSTS) (November 2012) · CISA, Binding Operational Directive 18-01, Enhance Email and Web Security (16 October 2017)
Check from outside
Does the site send a Content-Security-Policy header that says which origins its scripts, styles and frames may load from, rather than allowing anything?
Why
A content security policy is the browser-side limit that turns a cross-site scripting bug into a blocked request instead of a stolen session. The OWASP Secure Headers Project lists it first. Its absence is visible in one look at the response headers.
A passing result
- The Content-Security-Policy header on the main pages and the login page
- That it is not a permissive policy that allows every origin or inline script
Check from outside
Can your pages, especially the login and the portal, be loaded inside a frame on another site, or do they send frame-ancestors (in the content security policy) or X-Frame-Options to forbid it?
Why
Without a frame limit, an attacker can overlay your login in an invisible frame and trick a user into clicking or typing into it (clickjacking). OWASP's cheat sheet asks for frame-ancestors or X-Frame-Options on every page that holds a session.
A passing result
- The frame-ancestors directive or the X-Frame-Options header on the login and portal pages
- A test that the login page refuses to render inside a frame
Check from outside
Does the site send X-Content-Type-Options set to nosniff, and a Referrer-Policy that does not leak the full URL of internal pages to other sites?
Why
Without nosniff a browser may treat an uploaded file as a script; a loose referrer policy sends the full address of internal pages, including tokens in the query string, to every third-party resource. Both are one-line headers that OWASP recommends and a scan reports at once.
A passing result
- The X-Content-Type-Options header set to nosniff
- The Referrer-Policy header, set to no-referrer or same-origin for internal pages
Check from outside
Do the cookies that carry a session have the Secure, HttpOnly and SameSite flags, so they travel only over HTTPS, cannot be read by a script, and are not sent on cross-site requests?
Why
A session cookie without these flags can be stolen by a script or sent over plain HTTP. The flags are set in the Set-Cookie response header and are visible from the outside at login; OWASP treats them as a baseline.
A passing result
- The Set-Cookie header at login, with Secure, HttpOnly and SameSite present
- That no session cookie is sent over plain HTTP
Check from outside
Do the Server and X-Powered-By headers (and the login page's hidden version strings) hide the exact version of the web server, the language and the content management system?
Why
An exact version in a header tells an attacker which known vulnerabilities to try first, with no effort. AA23-278A lists weak configurations among the ten most common findings. Trimming the version banner is free and the result is visible in the response headers.
A passing result
- The Server and X-Powered-By headers, with no exact version number
- The page source and generator tags, with no exact CMS version
Sources: NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023) · OWASP Secure Headers Project and HTTP Security Response Headers Cheat Sheet (read on 11 November 2026)
Check from outside
From outside your network, do only the web ports (80 and 443) answer on your public addresses, with databases, remote desktop, SSH, file shares and management consoles not reachable from the open internet?
Why
Every open port is a door an attacker can knock on. The CISA "Stuff Off Search" guidance asks organisations to take management interfaces and services off the public internet and reach them over a private path instead. A free port scan of your own addresses shows what is open in minutes.
A passing result
- A port scan of your own public addresses, showing only 80 and 443 open
- That remote desktop, SSH, databases and admin consoles answer only over a private path or allow-list
Sources: CISA, Stuff Off Search (S.O.S.), reduce internet attack surface (read on 11 November 2026) · NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
Check from outside
Are the content-management login, database tools, staging and test copies, and vendor dashboards behind a login, an allow-list or a private network, rather than open to anyone who guesses the address?
Why
A forgotten staging copy or an open admin panel is a common way in, and search engines index them. The USCG rule 33 CFR 101.650 requires least privilege and an accurate inventory of the systems that are reachable; an exposed admin panel is neither.
A passing result
- The admin and database-tool addresses, each returning a login, an allow-list block or nothing from outside
- A list of staging and test sites, each closed to the public internet
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
Check from outside
When a visitor asks for a folder with no index page (for example an uploads or a backup folder), does the server return nothing or a 403, rather than an "Index of /" list of every file in it?
Why
An open directory listing hands an attacker the names of backups, documents and scripts to fetch next. It is a default that is easy to leave on and easy to test from the outside, one folder at a time.
A passing result
- A request to a folder with no index page, returning 403 or no listing
- No "Index of /" page anywhere a scan or a search engine finds
Sources: NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
Check from outside
Does your mail domain publish exactly one SPF record that lists the servers allowed to send mail in your name, and ends in a way that tells receivers to reject or mark the rest?
Why
Without SPF, anyone can send mail that appears to come from your terminal to your hauliers and partners. RFC 7208 defines SPF; a missing, duplicated or permissive SPF record is readable from the outside with a single DNS query.
A passing result
- The SPF (TXT) record of your mail domain, with the real sending servers listed
- That there is one SPF record, not two, and it does not end in a soft "allow all"
Check from outside
Is outgoing mail signed with DKIM, with the public key published in DNS, so a receiver can tell a real message from a forged one?
Why
DKIM (RFC 6376) lets a receiver verify that a message really came from your domain and was not changed. Together with SPF it is what a DMARC policy relies on. The public key is in DNS and the signature is in every message header.
A passing result
- The DKIM public key record in DNS for each selector you use
- A real message showing a passing DKIM signature
Sources: IETF, RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (September 2011)
Check from outside
Does your domain publish a DMARC record, is its policy stronger than "do nothing" (quarantine or reject), and do the aggregate reports go to a mailbox someone reads?
Why
DMARC (RFC 7489) ties SPF and DKIM together and tells receivers what to do with mail that fails: a policy of "none" only watches, it does not protect. CISA BOD 18-01 required federal domains to reach a reject policy. The record is public and a free checker reads it from the outside.
A passing result
- The DMARC (TXT) record, with its policy and the address its reports go to
- That the policy is quarantine or reject, or a dated plan to get there
Sources: IETF, RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) (March 2015) · CISA, Binding Operational Directive 18-01, Enhance Email and Web Security (16 October 2017)
Check from outside
Do any of your DNS records still point at a cloud service, bucket or subdomain you no longer use, which someone else could claim and serve content from your name?
Why
A record left pointing at a decommissioned service lets an attacker register that service and take over the subdomain, serving pages or collecting mail under your brand. It is invisible to your staff and visible to anyone who enumerates your subdomains from the outside.
A passing result
- A list of your subdomains and where each record points, with the dead ones removed
- That no record points at a service you no longer control
Sources: CISA, Stuff Off Search (S.O.S.), reduce internet attack surface (read on 11 November 2026)
Check from outside
Does your domain publish MTA-STS (and TLS reporting) so other mail servers must use TLS to reach you, and does your authoritative DNS refuse a full zone transfer to a stranger?
Why
MTA-STS (RFC 8461) stops a downgrade of mail-in-transit to plain text; an open zone transfer (AXFR) hands an attacker your whole list of names at once. Both are checked from the outside with a single query.
A passing result
- The MTA-STS policy and TLS-RPT record, if you accept mail
- A zone-transfer request from an outside address, refused
Sources: IETF, RFC 8461, SMTP MTA Strict Transport Security (MTA-STS) (September 2018) · IETF, RFC 8460, SMTP TLS Reporting (TLS-RPT) (September 2018)
Check from outside
Does the web server refuse to serve version-control folders (for example a .git directory), environment and configuration files, and leftover archives (.zip, .sql, .bak) to anyone who asks for them by name?
Why
An exposed .git folder or a .env file can hand over the whole source and its secrets; the incident behind this page began with a key committed in plaintext. These files are fetched by name from the outside, so a scan finds them even when nothing links to them.
A passing result
- A request for the common paths (a .git folder, a .env file, a database dump), each returning 403 or nothing
- No configuration or backup file reachable over HTTP
Sources: NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
Check from outside
When a page errors, does the visitor see a plain message, rather than a stack trace, a file path, a database query or the exact software version?
Why
A detailed error page is a map of your server: the framework, the file layout and sometimes a query an attacker can reuse. Turning off debug output in production is free, and the leak is visible by asking for a page that errors.
A passing result
- A deliberately bad request, returning a plain error with no path, trace or version
- That debug mode is off on the live site
Sources: NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
Check from outside
Do the HTML, JavaScript and comments that the site sends to every visitor contain no API keys, access tokens, internal hostnames or credentials?
Why
Anything in the page source is public: a key left in a script is read by the first person who looks, and found at scale by free secret-scanning tools. The CyberScan incident behind this page started from a committed secret; secrets in served code are the same leak, one step closer to the attacker.
A passing result
- A search of the served HTML and JavaScript for keys, tokens and passwords
- That internal hostnames and build paths are not left in comments
Sources: NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
Check from outside
Have you looked at what the certificate transparency logs, public search engines and internet-wide scan services already show about your names, subdomains and exposed services?
Why
Certificates are logged publicly, search engines index what they reach, and internet-wide scanners catalogue open services, so an attacker starts from a free map of your surface. Reading that same public map is the cheapest way to find a name or a service you forgot you had.
A passing result
- The list of your names from the certificate transparency logs, each still meant to be public
- A search of the public scan services for your addresses, with nothing exposed by surprise
Sources: CISA, Stuff Off Search (S.O.S.), reduce internet attack surface (read on 11 November 2026)
Check from outside
Does your site publish a security.txt file at the well-known path, giving a contact for anyone who finds a problem, so a finder tells you instead of posting it?
Why
RFC 9116 defines security.txt so a researcher who spots an exposed file or an expiring certificate has one clear, public address to warn you. Without it, the finder either gives up or goes public. The file is a few lines and is itself checked from the outside.
A passing result
- The security.txt file at /.well-known/security.txt, with a contact and an expiry date
- That the contact reaches someone who acts on it
Check from outside
Is there one list of your public names, their certificates, their DNS and mail records and their open services, with an owner for each, kept up to date?
Why
You cannot watch what you have not written down, and the surface grows every time a project adds a subdomain. The USCG rule asks for an accurate inventory of network-connected systems; the names and records that reach the internet are part of it, and the inventory is what a review starts from.
A passing result
- The inventory of public names, certificates, records and services, with an owner each
- The date it was last reconciled with a fresh outside scan
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · Directive (EU) 2022/2555 (NIS2), Article 21(2) (14 December 2022)
Check from outside
Do you run this outside check on a schedule and again whenever a certificate renews, a subdomain is added or a service is published, with the result going to the owner?
Why
A surface is correct the day you check it and drifts afterwards: a cert renews wrong, a staging site goes up, a record is added. IMO Rev.4 and NIS2 Art. 21 both ask for the regular review and improvement of the measures; a repeatable outside scan is how you see the drift before an attacker does.
A passing result
- The schedule of the outside check and who receives the result
- A change (a new subdomain, a renewed certificate) that triggered a fresh check
Sources: IMO, MSC-FAL.1/Circ.3/Rev.4, Guidelines on maritime cyber risk management (28 May 2026) · Directive (EU) 2022/2555 (NIS2), Article 21(2) (14 December 2022)
Free tools to check your own site
Two ways to look: public online checkers that run in a browser, described here in general terms with no brand named, and open-source tools you run yourself. The open-source projects are examples only, in alphabetical order inside each category, in their publisher's own words, with the licence their repository declares (read on 11 November 2026). This is not a ranking or a test, and commercial products exist in every category. Run any scanner only against names and addresses you own.
Read a site's certificate, its chain and expiry, and grade the protocol versions and ciphers it accepts, from the outside. Public online TLS test sites do the same in a browser, with no install.
- SSLyze: « Fast and powerful SSL/TLS scanning library. » (licence: AGPL-3.0)
- testssl.sh: « Testing TLS/SSL encryption anywhere on any port. » (licence: GPL-2.0)
Fetch a site's response headers and pages and report missing security headers, server banners, directory listings and known weak spots. Public online header-grading sites show the headers alone, with no install.
List which ports answer on an address and what service each one runs, so you see what is reachable beyond the website. Run them only against addresses you own.
Enumerate the subdomains and assets attached to a domain, from public sources such as the certificate transparency logs, so you find the names you forgot. Public online subdomain finders do a lighter version in a browser.
- OWASP Amass: « In-depth attack surface mapping and asset discovery. » (licence: see the repository's licence file)
- Subfinder: « Fast passive subdomain enumeration tool. » (licence: MIT)
Read your SPF, DKIM and DMARC records and your DNS delegation and report what is missing or wrong. Public online SPF/DKIM/DMARC checkers read the same records in a browser.
- checkdmarc: « A Python module and command line tool for validating a domain's DMARC, SPF, DKIM, and more. » (licence: Apache-2.0)
- Zonemaster: « a software that validates the quality of the delegation and configuration of a DNS zone. » (licence: BSD-2-Clause)
Scan your own source, pages and repositories for API keys, tokens and passwords, and for configuration or backup files that reach the web. The same family that caught the incident behind this page.
- Gitleaks: « Find secrets with Gitleaks. Detect and prevent secrets in your code. » (licence: MIT)
- TruffleHog: « Find, verify, and analyze leaked credentials. » (licence: AGPL-3.0)
What the public sources say
Every check names its paragraph. We quote only public texts and give their date; we name no terminal and no client.
Download the self-check checklist
One checklist, two formats. Version 1.0, published 11 November 2026. Set the weight of each line before you start, then ok, weak or fail for each name you check. There is no total: fix the « must » lines first. Check only names you own and are authorised to test.
Web exposure: questions
Click a question to read the answer.
More than most teams expect. From the public internet alone, before any password, they can read the certificate on every name you serve and when it expires, the security headers your site sends or omits, which ports and services answer beyond the website, what your DNS and mail records say about who may send mail for you, and any source-control folder, backup, error page or key you left reachable. This page is the same list, so you can look first.
Check only names your own organisation owns and is authorised to test. Pointing a free online checker at your own certificate, headers or mail records is a normal read of public information. A port scan or a secret scan runs only against addresses and repositories you own. If you want someone to look with you, that is what « request a scan » does: we scan only names you name and authorise in writing.
No. Most of the list can be checked with your browser and free online checkers: a TLS test site, a security-header grader, an SPF, DKIM and DMARC checker, the public certificate transparency logs. For the deeper checks the page lists open-source tools, named in their publisher's own words with their licence, that you run yourself against your own site. The checklist tells you what to look at; the tools are free.
Yes, each does a different job. SPF (RFC 7208) says which servers may send mail in your name; DKIM (RFC 6376) signs the message so a receiver can tell a real one from a forgery; DMARC (RFC 7489) ties the two together and tells receivers what to do with mail that fails, and sends you reports. A DMARC policy of « none » only watches: the aim is quarantine or reject.
It is a link to contact us, not a form that scans you on the spot. We agree in writing which names and addresses you own and want looked at, run the same outside checks this page describes, and send you a plain report with what we found and how to fix it. We never scan a name you have not named and authorised, and we name no other organisation.
Because the right tool depends on your site, your mail setup and your servers, and because prices and editions change. The page describes the public online scanners in general terms, names open-source examples in alphabetical order in their publisher's own words, and gives a checklist to review your own surface. Port Cyber Alliance does not certify sites.
Related pages
We agree which names you own and want checked, run the same outside review, and send you a plain report with what we found and how to fix it.
Ready to see your terminal from the outside?