Security scan
Once a week Glimana checks your site the way an attacker's scanner would look at it from outside: the certificate, security headers, files that should never be public, outdated software with known vulnerabilities, and your e-mail and DNS records. You get an A+ to F grade, the result of each of the 33 checks and, for every problem, how to fix it.
Open it from the sidebar: Data › Security. It is on every paid plan (Pro, Studio, Agency).
Who it runs for
The scan touches the site itself (for example, it asks whether /.env is public), so it runs only on sites whose owner is verified: a DNS, HTML file or meta tag verification in Glimana, or Owner or Full user access in Google Search Console. Restricted or read-only Search Console access is not enough. On an unverified site the Security page says so and nothing is requested.
When it runs
- The first time right after the site's first crawl.
- Then every Sunday at 04:00 (Istanbul time).
- On demand with Re-scan on the Security page: up to 2 scans per site and 6 per workspace per hour. Re-scanning needs the Crawls and tests permission.
A scan takes one to four minutes and sends a few dozen ordinary requests.
The 33 checks
| Group | What is checked |
|---|---|
| Certificate and HTTPS | Certificate validity and expiry, key strength, old TLS versions, weak ciphers, TLS 1.3, HSTS |
| Exposed files | .env, .git, backup and database dumps, debug pages and logs, directory listing |
| Outdated software | CMS version, WordPress plugins with known vulnerabilities, JavaScript libraries with known vulnerabilities |
| Security headers | Content-Security-Policy (missing or weak), clickjacking protection, nosniff, Referrer-Policy, Permissions-Policy |
| Cookies and cross-site access | Secure / HttpOnly / SameSite cookie flags, CORS that reflects any origin with credentials, Subresource Integrity |
| Information leaks | Server and framework versions in headers, the generator tag, error pages that print code, security.txt |
| E-mail and DNS | SPF, DMARC, dangling CNAME records (subdomain takeover), CAA, DNSSEC |
Every check has its own guide under Guides (keys start with sec_), linked from the Security page as Fix guide.
What it does not do
The scan only reads. It does not try passwords, does not tamper with parameters and does not crawl directories. Exposed files are checked on about 20 fixed paths, reading only the first 2 KB, and a file counts as exposed only when its content matches (a soft 404 does not). When it finds something it stops: it never downloads .git objects and never stores the contents of an .env file — the evidence shows only the names of the keys it saw.
The grade
The score starts at 100 and each failed check subtracts by severity: critical 30, high 15, medium 7, low 3, info 0.
| Grade | Score |
|---|---|
| A+ | 100 |
| A | 90–99 |
| B | 75–89 |
| C | 60–74 |
| D | 40–59 |
| F | below 40 |
A single critical finding caps the grade at D, however good the rest is: one public configuration file is not balanced out by good headers. Checks that could not be measured do not count either way. The security grade is separate from the site's health score; only critical and high findings also lower health, and only a little.
Reading the results
- Critical, High, Medium, Low, Info — the check failed with that severity; the row shows the evidence, how to fix it and a link to the issue. Problems are listed first in each group.
- Not running yet — the check could not run, with the reason (for example, the vulnerability data was still loading). When it becomes ready, it says it will run in the next scan.
- Could not be measured — the site did not give an answer the check could use (for example, a request timed out).
- Not applicable — the check does not apply to this site (for example, WordPress plugin checks on a site that is not WordPress).
- Passed — nothing to do.
Failed checks also appear on Issues (category Security) and become tasks, so they are prioritized and verified like everything else.
Alerts
When a scan finds a new or worse critical or high problem, Glimana raises an alert right away with the fix in one sentence and a link to the Security page. It goes to your notification channels, and by e-mail where your plan includes e-mail alerts.
Data sources
- WordPress plugin vulnerabilities: Wordfence Intelligence (© Defiant Inc.), refreshed daily.
- JavaScript library vulnerabilities: the retire.js database (Apache-2.0), refreshed weekly.
- Deep TLS test: testssl.sh (GPL-2.0), run as a separate program on our scanner.
API and AI assistants
The same result is available read-only through GET /api/v1/sites/{site}/security and the MCP tool get_security_scan; see API and MCP.