# How To Block Cloud-Metadata Requests With BetterShield?
On from the start: refuse requests plugins send to the addresses where a cloud server keeps its credentials, let your own services through, and undo it.
With **[BetterShield](/)**, on from the start: refuse requests plugins send to the addresses where a cloud server keeps its credentials, let your own services through, and undo it.
## What it does
A cloud server answers a request to its metadata address with facts about itself, and on several clouds with the credentials it runs under. Nothing on the internet can reach that address, but the server itself can, so a plugin that fetches whatever address it is handed can be pointed at it. **Server detail protection** refuses those requests, whichever plugin makes them. It is under **Hide site details** on **BetterShield › Protection › Hardening**. Unlike the other 29 fixes, it is on from the start: it is switched on when [BetterShield](/) is activated, and by the update that brought it on sites that already ran BetterShield. It has an undo like the rest.
- **Refuses a request to a cloud-metadata address** made through WordPress, whichever plugin makes it. In the fix's own words, that is "169.254.169.254 and the rest of the link-local ranges, 100.100.100.200, fd00:ec2::254 and metadata.google.internal, written out, spelled another way, or as a name that resolves to one of them."
- **Refuses a redirect that leads to one of them,** so an address that answers "go there instead" does not get around it.
- **Lets requests into this server's own network through.** They are never refused, so a search, cache or other service on a private address keeps working; each is noted in the activity log once a day for each address and plugin. Requests to this site's own address, which WordPress makes to run its schedule, are left alone.
- **Tells the plugin why.** The refused request gets "BetterShield refused this request because it was going to a cloud-metadata address, where a cloud server keeps its credentials. The activity log names the plugin that made it. If that plugin needs the address, let it through under Protection › Hardening.", and the activity log names that plugin.
- **Stands aside** on the store's cart and checkout, and in safe mode.
- **Writes no files,** and works on any web server.
What it does not reach: it sees only requests made through WordPress, so a plugin that opens its own connection goes around it.
## Step 1: Block Cloud-Metadata Requests
There is nothing to do to turn it on. Open **BetterShield › Protection › Hardening** and find **Server detail protection** under **Hide site details**: the row shows **On since** and **Undo never expires**. After the update that brought it, the release panel on the Overview says one of the things it added is already switched on, and lists this fix first: "On after this update."
Its one option is a list of addresses to let through. The field shows only while the switch is off, so to change it:
1. Turn the switch off.
2. Type the addresses in **Addresses to let through**.
3. Press **Preview the change**. It lists what applying would do, including "Lets these through, neither refused nor noted:" with your list. Nothing changes.
4. Turn the switch on again.
| Option | What it does | Default |
|---|---|---|
| **Addresses to let through** | "Only for something you run that a plugin here has to reach: host names, addresses or ranges such as 10.0.0.0/24, separated by commas. What is listed here is neither refused nor noted." Up to 50 entries, a range no wider than a /8 (a /16 for IPv6), and no wildcards. | Empty (the placeholder reads search.internal, 10.0.0.0/24) |
An entry it cannot use is named before anything changes: "“…” is not a host name, an address or a range that can be let through."
**Monitor first** cannot watch it in advance: while the fix is off, its panel points you to the preview instead. Other ways to change it:
- **WP-CLI:** `wp bettershield harden cloud_metadata --undo --user=admin` switches it off, and `wp bettershield harden cloud_metadata --allow=search.internal,10.0.0.0/24 --user=admin` switches it on with a list; `--dry-run` previews. To change the list from the terminal, undo it first. See [WP-CLI commands](/docs/wp-cli-commands/).
- **An AI assistant** allowed to make changes can apply it. Taking it off needs a plan you agree to.
Review the state and choices shown on your own site before applying a change.
## Recommended settings
We recommend leaving it on for every site. If one plugin really needs a metadata address, list that address under **Addresses to let through** rather than switching the whole fix off.
| Site | What we recommend |
|---|---|
| A site on a cloud server | Leave it on. These addresses are where the server keeps its credentials. |
| A site whose search, cache or other service runs on a private address | Leave it on. Those requests already go through; list the address if you would rather they were not noted. |
| Agency or many sites | Leave it on everywhere, and read the activity log for refused requests after adding a new plugin. |
## What it can break, and how to undo
- **A plugin that needs one of these addresses.** Its request is refused with the message above, and the activity log names it. Let the address through (switch off, list it, switch on), or leave the fix off.
- **Requests into your server's own network** are not broken: they go through and are only noted.
- **The store's cart and checkout** are not touched, because it stands aside there.
To undo, turn the switch off. In the fix's words, "A request to a cloud-metadata address goes out again, and requests into this server’s own network are no longer noted." "Hardening undone" is logged, rated High because it was switched off by hand, so [email alerts](/docs/email-alerts/) send it as it happens. With **Ask for my password before removing a protection** on, that asks for your password. Once you switch it off, it stays off: later updates and reactivating BetterShield do not switch it on again. Safe mode pauses it, and deactivating BetterShield stops it.
## Final Outcome
**The row.** **On since**, **Undo never expires**, and "This one has no effect a page view can check, so it is reported from your settings."
- **The activity log.** "Hardening applied" when it was switched on, at activation or at the update. "Request to a cloud-metadata address refused" (Medium) names the plugin that made the request, and "Request into this server’s own network" notes one that was let through.
- **Findings.** It has no finding of its own. While it is on, **Some protections that are switched on are not working** (Medium) names it if it reads as on but is no longer in force, for example because another plugin took it off.
- **From the terminal.** `wp eval 'var_dump( wp_remote_get( "http://169.254.169.254/" ) );'` prints an error carrying the refusal above, straight away, and the activity log records it.
Example Cloud-metadata block view. Check the saved values and status on your own site.
## On multisite
Each site has its own switch.
## Related
- [Hardening](/docs/hardening/)
- [Hide the WordPress version](/docs/hide-wordpress-version/)
- [Hide usernames](/docs/block-user-listing/)
- [Activity log](/docs/activity-log/)
- [What BetterShield contacts](/docs/what-bettershield-contacts/)
- [Score and findings](/docs/score-and-findings/)
This is how you can block cloud-metadata requests with BetterShield.
Getting Stuck? Feel free to contact our [Dedicated Support Team](/support/).
