HTTP security checker
Most web security failures are not clever attacks. They are a header that was never set, or a version number the server volunteers to anyone who asks. Point the scanner at a site you control and get the headers and the technologies behind it - graded, kept, and watched for the day any of it changes.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
Six reasons to check your own HTTP layer
Headers are the cheapest security work there is. They are configuration, not code, and most of them are one line.
01
Find the headers that were never set
Security headers are the instructions a site gives the browser about how to treat it. Without them the browser applies its defaults, which are permissive by design because the web has to keep working for sites written twenty years ago. Nothing breaks when a header is missing, which is precisely why it stays missing.
02
Stop the server from introducing itself
A default install often announces its software and version in every response. That is not a vulnerability on its own, and it is also the first thing an attacker reads - it turns "find a way in" into "look up the known flaws in this exact version". Turning the banner off costs nothing.
03
Check the headers that only apply on the right page
Strict-Transport-Security on the marketing homepage and not on the login page is a common and quiet failure. Cookie flags are the same: Secure and HttpOnly set on one cookie and forgotten on the session cookie. Testing one URL tells you about one URL.
04
See which technologies you are actually running
The response usually reveals the framework, the server and often the CMS. Knowing what is detectable from outside is the starting point for knowing whether any of it is out of date - and it is frequently not the version the team believes is deployed.
05
Catch what a deploy quietly removed
Headers live in configuration that gets replaced: a new reverse proxy, a CDN added in front, a framework upgrade that resets defaults. The site looks identical afterwards. The headers are gone, and nobody looks at headers unless something is wrong.
06
Produce evidence for a security review
A customer's security questionnaire asks whether you set a Content-Security-Policy. A dated report showing which headers each host returns is a better answer than a tick in a box, and it is evidence you can keep.
Know the day your configuration changes
An HTTP configuration does not drift gradually. It changes in one deploy, and the change is invisible in the browser.
Scheduled scans turn that into a difference you are told about: this header disappeared, this technology version went backwards, this grade dropped. Alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the target
A hostname or a domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Choose the profile
Three depths. Passive reads what the site returns without probing it. Active sends test requests to find weaknesses that only appear under them. Extended goes further again. Passive is safe against anything; the deeper profiles are real traffic and should be pointed at what you expect them to touch.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F. HTTP carries the heaviest weight in the composite grade - 30%, more than any other layer - because it is where most of what is reachable actually lives.
What the scan checks
01
Security headers
Which ones are present, which are missing, and whether the values are doing what they look like they are doing. A Content-Security-Policy that allows everything is present and useless.
02
Technology detection
The server, framework and libraries that the responses reveal, with versions where they are disclosed.
03
Known web vulnerabilities
Once you sign in for the active or extended profile, the scan is powered by OWASP ZAP, the open source web application scanner maintained by the Open Worldwide Application Security Project and the tool this category is measured against. The quick check above stays passive: no ZAP, no probing, just the one request needed to read the headers.
Questions before you scan
What may I scan?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the target to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
Will the scan disrupt the site?
The passive profile will not - it reads responses to ordinary requests. The active and extended profiles send test requests by design, which is how they find things passive checks cannot. Point those at an environment you are prepared to have probed.
Is this a penetration test?
No, and it does not replace one. An automated scan finds the classes of problem that can be found automatically. A penetration test is a person looking for the ones that cannot.
We use a CDN. Am I testing my site or theirs?
Both, and that is worth knowing. The headers a visitor receives are the ones the CDN sends, whoever set them. If your origin sets a header the CDN strips, the visitor does not get it - and the scan shows you what the visitor gets.
Do missing headers really matter?
Individually, often not much. Collectively they are the difference between a browser that defends your users and one that does whatever it is told. They are also the cheapest fix on any security backlog, which makes them a poor thing to still have open.
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the target to an AYAsec account instead, and every scan is kept - a series that tells you which deploy removed the header. Retention depends on your plan.
Keep the history, not just the result
Run the full scanner against your own estate, on a schedule, with every result retained and every change flagged.
More free security scanners for TLS, ports and DNS
HTTP is one of five scored layers. The others each answer a different question:
Online port scanner
what is this estate willing to talk to a stranger about?
SSL/TLS checker
is the encryption sound, and when does the certificate expire?
DNS security checker
can anyone send mail that looks like it came from you?
All five together are what attack surface management means in practice.