Cloudflare Tunnel - Protect Quick Tunnels with email authentication
Quick Tunnels can now be restricted to specific email addresses using the --allowed-mail flag in cloudflared, requiring visitors to authenticate with a one-time PIN before accessing the local service. This enables secure sharing of development servers and demos without requiring visitors to have a Cloudflare account.
You can now restrict who can access a Quick Tunnel. Use the new --allowed-mail flag in cloudflared to require visitors to authenticate with a one-time PIN sent to their email before they reach your local service.
cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com
Previously, anyone with a trycloudflare.com URL could access the service behind it. Protected Quick Tunnels let you share a local development server, webhook receiver, or demo with specific people without creating a Cloudflare account or configuring a domain.
You can allow:
- A single email address:
--allowed-mail alice@example.com - Multiple email addresses, by repeating the flag or using a comma-separated list:
--allowed-mail 'alice@example.com,bob@example.com' - Every address on a domain:
--allowed-mail '*@example.com'
Visitors do not need a Cloudflare account. Access ends for everyone when you stop the cloudflared process.
To get started, update cloudflared to the latest version and refer to Restrict access by email.
Source: original entry ↗
More from Cloudflare
Follow Cloudflare to get its new changes in your feed and email digest.
API Shield - Run schema learning on demand
API Shield now supports on-demand schema learning runs, allowing you to manually trigger learning after sending representative traffic to your API instead of waiting for the weekly schedule. This enables faster testing and validation cycles.
Cloudflare API MCP server now serves Cloudflare skills
The Cloudflare API MCP server now integrates with the Skills over MCP extension, allowing MCP clients to discover and access Cloudflare skills. Users can add the MCP server endpoint to compatible MCP clients to access these skills.
WAF failed detections field now available in Rules
A new cf.appsec.request.failed_detections field lets you control how rules handle requests when security detections fail. This array of detection IDs covers content scanning, WAF attack scoring, attack signatures, leaked credentials, and AI-based PII/prompt injection/custom topic detection failures, and works across custom rules, rate limiting rules, and request header transform rules.