Mastodon Authorized Fetch Mode: When to Enable It

Mastodon instances communicate with each other to exchange public posts and profile data. This open federation model can be abused by malicious servers that scrape content or bypass blocks. Authorized Fetch Mode, also known as Secure Mode, forces every server-to-server request to include a signed authentication header. Enabling this setting stops unauthorized servers from pulling public data from your instance. This article explains how Authorized Fetch Mode works, when you should turn it on, and what trade-offs to expect before enabling it.

What Authorized Fetch Mode Does in Mastodon

Mastodon uses the ActivityPub protocol to share posts, profiles, and notifications between instances. By default, any server on the internet can make an HTTP GET request to your instance and read public data such as toots, media attachments, and profile metadata. This is how the federated timeline works—your instance sends data to other servers without requiring them to prove their identity.

Authorized Fetch Mode changes this behavior. When enabled, your instance rejects any incoming ActivityPub request that does not include a valid HTTP Signature header. The requesting server must sign the request with its own private key. Your instance then verifies the signature using the requesting server’s public key, which is fetched from that server’s actor object. Only after successful verification does your instance serve the requested data.

How the Signature Handshake Works

The process follows these steps:

1. Requesting server generates a signature
   The remote server creates an HTTP Signature using its private key and includes headers such as Date, Host, and Digest in the signature string.
2. Your instance receives the request
   Your server reads the Signature header, extracts the keyId URL, and fetches the remote server’s public key from that URL.
3. Signature verification
   Your instance recomputes the signature using the public key. If the signatures match, the request is accepted. If not, the request is rejected with a 401 Unauthorized response.

When to Enable Authorized Fetch Mode

Authorized Fetch Mode is not enabled by default. The decision depends on your instance’s threat model and performance requirements. Enable it in these scenarios:

• Your instance is a target of data scraping — If you run a popular instance that attracts bots or scrapers, Authorized Fetch Mode blocks unauthorized bulk data collection.
• You have blocked a large number of instances — Blocked servers can still read public data through unauthenticated requests. Authorized Fetch Mode enforces those blocks at the API level.
• You want to prevent federation with malicious servers — Servers that cannot sign requests (such as custom scrapers or outdated software) are automatically denied access.
• Your instance hosts sensitive content — Even public posts may contain personal information. Requiring authentication adds a barrier against casual harvesting.

Steps to Enable Authorized Fetch Mode

You must be an administrator of a Mastodon instance to change this setting. The option is available in the web interface under Server Settings.

1. Log in as an admin
   Open your instance’s URL and sign in with an account that has the Admin role.
2. Navigate to Server Settings
   Click the hamburger menu (three horizontal lines) in the top-right corner. Select Preferences, then Administration, then Server Settings.
3. Find the Authorized Fetch option
   Scroll down to the section labeled Federation. You will see a toggle labeled Authorized Fetch or Secure Mode.
4. Toggle the setting on
   Click the toggle switch to enable Authorized Fetch Mode. The change takes effect immediately. No server restart is required.
5. Verify the change
   Use a tool like curl to attempt an unauthenticated GET request to a public endpoint on your instance. Example: curl -I https://yourinstance.social/api/v1/timelines/public. The response should return a 401 status.

Trade-offs and Limitations of Authorized Fetch Mode

Enabling Authorized Fetch Mode introduces several operational considerations. Evaluate these before turning it on.

Increased Server Load

Every incoming federated request now requires signature verification. For a small instance with fewer than 100 active users, the additional CPU load is negligible. For large instances with thousands of active federations, the verification process can increase server response times by 10 to 50 milliseconds per request. Under heavy traffic, this may cause noticeable delays in timeline updates.

Federation Compatibility Issues

Some older or custom ActivityPub implementations do not support HTTP Signatures. These servers will be unable to fetch any data from your instance. As a result, your public posts will not appear in their federated timelines. Users on those instances will not see your content unless they follow your account from within your instance.

Search Engine Indexing

Search engines such as Google and Bing rely on unauthenticated HTTP requests to index public content. Authorized Fetch Mode blocks these crawlers. Your public posts will not appear in search results. If you rely on search engine visibility for your instance or your content, keep this mode disabled.

Partial Block Bypass Prevention

Authorized Fetch Mode prevents blocked servers from reading public data through the API. However, it does not prevent a blocked server from receiving data through a third-party server that has not been blocked. A user on a blocked instance could still see your public posts if another unblocked instance relays them. This is a limitation of the ActivityPub protocol itself, not of Authorized Fetch Mode.

Authorized Fetch Mode vs Default Federation: Key Differences

Item	Default Federation	Authorized Fetch Mode
Authentication requirement	None — any HTTP GET is accepted	HTTP Signature required for all requests
Block enforcement	Blocked servers can still read public data via API	Blocked servers are denied at the API layer
Search engine indexing	Public posts are indexed by search engines	Public posts are not indexed
Federation compatibility	Works with all ActivityPub implementations	Incompatible with servers lacking HTTP Signature support
Server load	Minimal — no signature verification	Increased — each request requires signature verification

You now understand how Authorized Fetch Mode works and when to enable it. If your instance faces scraping attacks or you need to enforce blocks strictly, turn on the feature in Server Settings under Federation. Monitor your server’s CPU usage after enabling it. For most small to medium instances, the security benefit outweighs the performance cost. Consider leaving Authorized Fetch Mode disabled if search engine visibility or broad federation compatibility is more important than blocking unauthorized access.