Protecting your site

Your sites come protected out of the box: BOA switches on a set of access protections for every site, and your host keeps them current. This topic covers the handful of decisions that are yours — opting out of a built-in guard when it's genuinely in your way, locking things down further with your own IP allow-lists, and deciding which AI bots may read each site.

• Restricting access to your site — the protections BOA turns on for you (the /admin* page protection among them), what each one does, and how to opt out of one per site when you need to.
• Site IP lock — make a whole site reachable only from IP addresses you list: intranets, staging copies, admin-only tools.
• Login/admin IP lock — keep a site public while its /user and /admin pages answer only to your own addresses.
• AI crawlers — which classes of AI bot may read each of your sites: training crawlers are blocked for you by default, AI search and assistant fetchers are allowed, and one control file changes it per site.
• Load testing — why a load test fired from a single address measures the protection instead of your site, and how to run a performance test that produces real numbers.
• Attacks that never reach your site — what the server refuses before your site ever sees it (probes, secret-file fishing, injection payloads, scrapers, floods), how offenders are blocked by behaviour, and what keeps the site standing during a swarm.

Everything here happens in your own world — a small control file in your account or a line in an INI file, never root and never the server. Which of your files to edit, and why a change takes about a minute to show up, is explained in Which file do I edit?; the per-line reference for the access-control settings is on INI settings.