Area: Website and certificates
Standard public files
Reads the three files a website publishes on purpose at fixed, standard locations: robots.txt, sitemap.xml and /.well-known/security.txt. One request to each, nothing more. It doesn't open any of the paths they mention or try others: Ward doesn't probe paths.
What it can report
Open each one to see what it means and how to fix it.
robots.txt lists sensitive paths
What it means
Your robots.txt is a public file where your website asks search engines to skip certain paths. Anyone can read it, so it also shows which areas you'd rather keep out of sight, and some of them look sensitive, such as admin areas or backups. Ward only read the file: it didn't open any of those paths.
What could happen
A list of hidden areas tells a stranger where to look. If one of them, say an admin panel or a folder of backups, isn't properly protected, finding it takes seconds. Hiding a path from search engines doesn't protect it: it only stops it from showing up in searches.
How an attacker would use it
Someone reads the public files of your website and notices a path that sounds like an admin area. They open it, find a sign-in page protected only by a weak password, and guess it. Hidden isn't protected: the file told them exactly where to knock.
How to fix it
- Go through the list and note what each path is for: a panel, a private area, an internal tool or something that no longer exists.
- For each one still in use, check that it asks for a password and, ideally, for two-step verification.
- Limit the sensitive areas (admin panels, internal tools) to your office addresses or a VPN if you can.
- Remove from the file the paths that no longer exist, so it doesn't point to old areas.
- Don't rely on robots.txt to hide anything: whatever must be private needs a login, not just a line in a file.
How to check it's fixed
If the paths are protected and you want to keep them listed, mark the finding as accepted with a note. Mark the finding as “Pending verification” and Ward will check it again within a minute or two. Once the problem is gone, it moves to “Resolved” on its own.
Who usually fixes it
Your IT person
Example with sample data. In your dashboard, the explanation uses your own domain and details.
sitemap.xml lists sensitive pages
What it means
Your sitemap.xml is a public file that lists the pages of your website so search engines find them. It's normal and useful. Ward only counted the addresses: it didn't open any of them.
What could happen
It isn't a risk in itself. The only thing to watch is that the list doesn't include pages you don't want to be public, such as drafts, test pages or private areas, because anyone can read the file.
How to fix it
- Open your sitemap.xml in the browser and skim the list of pages.
- Look for pages that shouldn't be public: drafts, tests, internal areas or old campaigns.
- Ask whoever manages your website to remove them from the sitemap.
- If any of those pages must stay private, protect it with a login: removing it from the sitemap only hides it from searches.
How to check it's fixed
It's informational, so there's nothing to fix if the list is what you want to publish. Mark the finding as “Pending verification” and Ward will check it again within a minute or two. Once the problem is gone, it moves to “Resolved” on its own.
Who usually fixes it
vosotros
Example with sample data. In your dashboard, the explanation uses your own domain and details.
security.txt has problems
What it means
Your website publishes a security.txt, the standard file where someone who finds a security flaw can see whom to tell. It's a good practice and there's nothing to fix: it's here as good news.
What could happen
There's no risk here. Just keep in mind that a contact nobody reads is as useless as none: an outdated address means a warning about a real flaw could get lost.
How to fix it
- Check that the contact in the file still works and that someone reads that mailbox.
- Renew the “Expires” date before it passes: an expired file is treated as outdated.
- Decide who answers a report and how fast. Even a short acknowledgement is enough.
How to check it's fixed
There's nothing to fix. If you change the contact or the date, Ward reads the file again in the next scan.
Who usually fixes it
vosotros
Example with sample data. In your dashboard, the explanation uses your own domain and details.
No security.txt
What it means
security.txt is a small public file, in a fixed place on your website, that tells whoever finds a security flaw whom to contact. Your website doesn't have one, or the one it has doesn't include a contact. Ward only looked at that one fixed address.
What could happen
Without it, a well-meaning researcher or customer who spots a flaw may not know whom to write to, and may give up or make it public instead. It isn't a flaw in itself, but it makes a timely warning less likely.
How an attacker would use it
A customer notices that your online shop shows other people's orders. They look for a security contact, find none and write to a general address that nobody checks. Weeks later the flaw is still open, and someone less friendly finds it too.
How to fix it
- Choose a mailbox that someone reads, such as security@yourcompany.com, or a page with a contact form.
- Write a text file with a “Contact:” line (for example mailto:security@yourcompany.com) and an “Expires:” date no more than a year away.The format is the RFC 9116 standard; the file is plain text.
- Ask whoever manages your website to publish it at the fixed address /.well-known/security.txt.
- Decide who answers a report and how fast. Even a short acknowledgement is enough.
- Set a yearly reminder to renew the “Expires” date.
How to check it's fixed
Mark the finding as “Pending verification” and Ward will check it again within a minute or two. Once the problem is gone, it moves to “Resolved” on its own.
Who usually fixes it
Your IT person
Example with sample data. In your dashboard, the explanation uses your own domain and details.