A checklist for people and AI agents. Outside check, inside check and fixes.
One page to check your website yourself, hand it to an AI agent, or hand it to us. Every item says what should hold, how to verify it and when it passes.
00 · How to use this page
The checklist is the same for everyone. Only who goes through it differs.
Items are grouped by area. Each has a command or tool to verify it.
Send the agent the page address and one of the prepared prompts. Ground rules and output format are part of the checklist.
Outside check, inside check, or straight to fixes. We take over access only for the time of the work.
For AI agents, the page is also available as plain text (markdown): https://vrealmatic.com/web/security.md
01 · Outside and inside
The outside check needs only the website address. The inside check needs access, but finds weaknesses that are invisible from outside.
| outside Outside | inside Inside | |
|---|---|---|
| What it needs | Only the website address. | Read-only access: accounts, repository, server. |
| Point of view | An attacker who knows nothing about the site. | An administrator who sees the settings. |
| What it finds | Encryption, security headers, DNS and e-mail, publicly reachable files, cookies. | Accounts and 2FA, permissions and API tokens, dependencies, secrets in code, the server, backups. |
| What it misses | A former colleague with valid access, a backup that cannot be restored, an outdated plugin in the admin. | Nothing extra. The inside check also covers every outside item. |
| Who can do it | Anyone, including an AI agent with web access only. | You, an AI agent in the website repository, or us with your permission. |
An attacker often needs no clever attack. A leaked password without 2FA, a forgotten plugin or a key in the repository is enough. These are exactly the items you cannot see from outside.
02 · Checklist
Every item has a code, a scope and a severity. Outside items need only the website address, inside items need access. Replace your-site.com with your domain.
Severity: high = fix now, medium = within a month, low = at the next maintenance.
An encrypted connection protects logins, forms and content from eavesdropping and tampering.
curl -sI http://your-site.com and the same for the www variant.Location: https://… for every variant of the domain.openssl s_client -connect your-site.com:443 -servername your-site.comcurl -sI https://your-site.com, look for Strict-Transport-Security.max-age of at least 31536000 (one year). preload only after checking that every subdomain supports HTTPS.Headers tell the browser what the page may load and how it may be displayed. They block injected scripts and framing of the page by another site.
curl -sI https://your-site.comframe-ancestors. No unsafe-inline for scripts where avoidable.frame-ancestors in the CSP, or the X-Frame-Options header.frame-ancestors 'self' or 'none', alternatively X-Frame-Options: DENY.X-Content-Type-Options header.X-Content-Type-Options: nosniffReferrer-Policy and Permissions-Policy headers.strict-origin-when-cross-origin or stricter. Camera, microphone and location off unless the site needs them.Server and X-Powered-By headers, the generator meta tag.The most common leak is not an attack. A file stays on the server that should not be there, or a key ends up in browser code.
/.env, /.git/config, /backup.zip, /dump.sql, /phpinfo.php. For example curl -s -o /dev/null -w "%{http_code}" https://your-site.com/.envsk_live_, service_role, secret, api_key, Bearer.//# sourceMappingURL=…, then try to download the .map./?id='.staging., dev., test., hosting preview addresses (*.workers.dev, *.vercel.app, *.netlify.app)./uploads/ or /wp-content/uploads/.Whoever controls the domain controls the website and the e-mail. Poorly configured e-mail lets others send fraudulent messages in your name.
dig TXT your-site.com, dig TXT _dmarc.your-site.com or Internet.nl.-all or ~all, DKIM signs outgoing mail, DMARC has p=quarantine or p=reject.v=spf1 -all and DMARC p=reject. Otherwise it can be abused as a sender.dig CAA your-site.comdig +dnssec your-site.comEvery form is an entry into the application. From outside it is checked passively only; real input handling shows only in the code.
Most website administration rests on accounts: hosting, CDN, domain, repository, CMS. Each one is a way into the website.
/admin, /wp-admin, /wp-login.php, /administrator.A login cookie is the key to an account. It must travel encrypted only and must not be readable by scripts.
Set-Cookie in the response.Secure, HttpOnly, SameSite=Lax or Strict.A website largely runs on other people's code: libraries, plugins, themes. Their vulnerabilities are the website's vulnerabilities.
npm audit, OSV-Scanner, Dependabot, for WordPress the updates overview in the admin..env is in .gitignore. Any key that ever appeared in the history has been rotated.npm ci (or equivalent), who may change CI and deployment.With managed hosting, the provider is responsible for most of this. With your own server and CDN, the settings are up to you.
/etc/ssh/sshd_config), firewall, automatic updates.A backup is worth something only if the website can be restored from it, and only if an attacker cannot delete it together with the website.
A problem you learn about right away is a smaller problem. A few alerts and a clear procedure are enough.
curl -s https://your-site.com/.well-known/security.txtContact: and a valid Expires: (RFC 9116).03 · For AI agents
Send the AI agent the address of this page's markdown version and one of the prompts. An agent with web access only can handle the outside items. An agent running in the website repository with read-only access can handle the inside items too.
For an agent with web access (search and page fetching, optionally a terminal with curl and dig).
Check the security of https://your-site.com against this checklist:
https://vrealmatic.com/web/security.md
Scope: only items labelled "outside". You have the public address only, no access.
Follow the "Ground rules for the agent".
Output: a table as described in "Output format", most severe issues first.For a coding agent (e.g. Claude Code) running in the website repository, optionally with a read-only token for Cloudflare or the hosting.
Check the security of https://your-site.com against this checklist:
https://vrealmatic.com/web/security.md
Scope: all items. Verify "inside" items in this repository and in the access
you have. Mark anything you cannot verify as "cannot verify" and say which access is missing.
Change nothing. Never print secret values, give only the file and line.
Follow the "Ground rules for the agent".
Output: a table as described in "Output format", most severe issues first.One row per item. Status: pass, issue, cannot verify or not applicable. Severity is taken from the checklist. Below the table, a short summary: the three most important steps.
| Item | Status | Severity | Finding and evidence | Fix |
|-------|---------------|----------|----------------------------------|-------------------------|
| EXP-1 | issue | high | /.env returns 200 with DB_* | Block, rotate passwords |
| TLS-4 | issue | medium | No Strict-Transport-Security | Add HSTS |
| BAK-2 | cannot verify | high | No access to the hosting | Test restore |The checklist above covers everyday website operation. For a deeper look at code and the application, these kits help.
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-auditInstalling the cloudflare/security-audit-skill skill. The agent then audits the code of the repository it runs in (e.g. “security audit this codebase”). It belongs to the inside check, not the outside one.
04 · Service
You can go through the checklist yourself. If you lack the time or want certainty, we go through it for you. In three options, depending on how deep you want to go.
No access, the website address is enough
A report with findings by severity and proposed fixes.
Read-only access for an agreed period
A report and a fix plan: what now, what within a month, what ongoing.
Temporary write access, only for the fixes
A change report with steps to revert. Access revoked at the end.
We agree on the option, scope and date. We find out where the website runs and who has access to what.
None for the outside check. For the inside check you create our own read-only account, for fixes temporarily with write access.
We go through the checklist. We fix only after you approve the plan, and log every change.
You receive the report. Access is revoked, and keys we saw during the work are rotated.
05 · Access
Taking over access is a matter of trust. That is why it follows fixed rules you can verify at any time.
| Where | Inside check | Check and fix |
|---|---|---|
| Cloudflare | Account member with the Administrator Read Only role | A role scoped to the given domain (zone) |
| GitHub / GitLab | Read access to the repository | Write to a branch, changes via a pull request you approve |
| Server (SSH) | Own user with an SSH key, no sudo | Temporary sudo rights |
| Hosting and CMS | The lowest role that shows the settings. Where none exists, screen sharing. | A temporary administrator account |
| Domain registrar | Screen sharing or screenshots of the settings, no access needed | You make the changes following our steps |
| Database | Read-only user | Write access only if a fix targets the data |
Then we use screen sharing: you click, we watch. It takes longer, but access stays with you only.
06 · Summary
Sources
The checklist builds on public standards and provider documentation.
How to cite this publication (APA 7)Nepor, V. (2026, October 23). Secure Website Operation: a Checklist for People and AI Agents. Vrealmatic. https://vrealmatic.com/web/security
We agree on the scope, access and date. You can start with an outside check, which needs no access at all.