Three Layers of Power Pages Security: CAPTCHA, WAF, and Azure DDoS Protection

When designing a public-facing Microsoft Power Pages website, three security controls frequently appear: CAPTCHA, Web Application Firewall (WAF), and Azure DDoS Protection. Although all three help address malicious traffic, they operate at different layers, have different scopes, and cannot replace one another.

In one sentence:
Azure DDoS Protection mitigates large-scale network attacks; WAF inspects and limits web requests reaching Power Pages; and CAPTCHA helps determine whether a critical form action is being performed by a human or a bot.

1. The Overall Security Architecture

Internet
   │
   ▼
Azure DDoS Protection
Mitigates network floods and connection-exhaustion attacks
   │
   ▼
Power Pages WAF
Inspects HTTP requests, attack patterns, bots, and request rates
   │
   ▼
CAPTCHA
Protects registration, application submission, and other critical actions
   │
   ▼
Power Pages Table Permissions
   │
   ▼
Microsoft Dataverse
  

This is a defence-in-depth architecture. The outer controls handle large-scale traffic, while the inner controls progressively protect web requests, user actions, and access to business data.

2. CAPTCHA: Protecting Critical Form Actions

What CAPTCHA does

CAPTCHA is a human-verification mechanism designed to reduce automated abuse of website forms.

It is commonly used to reduce:

• Automated spam submissions
• Bulk account creation
• Large numbers of application records created in a short period
• Credential-stuffing attempts using previously compromised credentials
• Scripts repeatedly triggering emails, notifications, or Power Automate flows

Scope of CAPTCHA

CAPTCHA primarily protects a specific form or user action, not the entire website. Power Pages can display CAPTCHA to anonymous users, authenticated users, or both.

Typical actions that may benefit from CAPTCHA include:

• User registration
• Password-reset requests
• Creating a formal application
• Final application submission
• Other anonymous forms that trigger backend processing

Power Pages provides a built-in CAPTCHA control and also supports custom CAPTCHA providers that meet an organization’s security, privacy, accessibility, and regional requirements.

Microsoft references: Add forms in Power Pages and Configure a custom CAPTCHA provider .

What CAPTCHA does not do

• It does not stop large-scale traffic attacks against the website or its static resources.
• It does not inspect requests for SQL injection or cross-site scripting.
• It does not scan uploaded files for malware.
• It does not replace Power Pages table permissions.
• It does not replace server-side Dataverse authorization and validation.
• It cannot guarantee that every advanced bot will be blocked.

3. Power Pages WAF: Inspecting Web Requests

What WAF does

WAF stands for Web Application Firewall. Power Pages WAF is powered by Azure Front Door. When WAF is enabled, website traffic is inspected before approved requests are forwarded to Power Pages.

WAF capabilities include:

• Detection of SQL injection and other injection attacks
• Detection of cross-site scripting (XSS)
• Microsoft-managed security rules
• Malicious and unidentified bot protection
• Allowing or blocking requests by source IP address
• Geographic access restrictions
• Rules targeting specific request URIs
• Rate limiting over a defined period
• Firewall logs for traffic analysis and incident investigation

Scope of WAF

Power Pages WAF is configured at the individual website level. It is not a single tenant-wide switch.

For example, one tenant may contain:

• A COA development website
• A COA QA website
• A COA production website

The WAF status and rules for each website must be reviewed separately. The native Power Pages WAF capability is available for websites with the Production application type. Trial sites are not supported.

Microsoft reference: Web Application Firewall for Power Pages .

WAF rate-limiting example

Consider an automated program that repeatedly sends requests to an application-submission endpoint. Each request might be a correctly formatted HTTPS request, but the repeated activity could still create unwanted Dataverse records or consume backend resources.

A WAF rule could apply a limit similar to the following:

For the same source IP address:
Allow no more than 20 requests
to the application-submission endpoint
within five minutes.
Block additional requests that exceed the threshold.
  

The actual threshold should be based on normal website traffic. A limit that is too restrictive could affect legitimate users from offices, schools, or public networks where many people share the same public IP address.

What WAF does not do

• It does not scan SharePoint documents for malware.
• It does not replace Dataverse security roles or Power Pages table permissions.
• It does not prove that a person submitting a form is human.
• It does not independently handle every large-scale network-layer attack.
• Its rules must be tested and monitored to avoid blocking legitimate traffic.

4. Azure DDoS Protection: Protecting Platform Availability

What is a DDoS attack?

DDoS stands for Distributed Denial of Service. In a DDoS attack, an attacker uses a large number of computers, servers, or compromised devices to send traffic to a public website simultaneously.

The objective is to exhaust network bandwidth, connections, or processing capacity so that legitimate users can no longer access the service.

What Azure DDoS Protection does

Azure DDoS Protection primarily addresses network-layer and transport-layer attacks, commonly referred to as Layer 3 and Layer 4 attacks.

Typical examples include:

• Large-scale traffic floods
• Network protocol attacks
• Connection-exhaustion attacks
• Abnormal traffic originating from many distributed sources

Scope of Azure DDoS Protection

Power Pages is built on Microsoft Azure and uses Azure DDoS Protection as part of its platform-level protection.

Because Power Pages is a Microsoft-managed SaaS service, its underlying DDoS protection is managed by Microsoft. A Power Pages project normally does not need to develop its own DDoS capability or call a DDoS service from application code.

Microsoft references: Power Pages security FAQ and Azure DDoS Protection FAQ .

Why is WAF still needed?

Azure DDoS Protection and WAF protect different layers:

• Azure DDoS Protection evaluates whether network traffic is attempting to exhaust platform resources.
• WAF evaluates the content, source, URI, pattern, and frequency of individual HTTP requests.

A group of requests might not be large enough to constitute a network-layer DDoS attack, but it could still repeatedly call an expensive business endpoint. WAF rules and rate limiting are more appropriate for this application-layer scenario.

5. Comparison of Responsibilities

Security control	Primary layer	Scope	Primary threats	Configuration responsibility
CAPTCHA	User-action layer	Forms where CAPTCHA is enabled	Bots, spam submissions, and bulk registrations	Power Pages administrators or the development team
Power Pages WAF	Application layer, Layer 7	An individual production website	Malicious HTTP requests, web attacks, and abnormal request rates	Power Pages administrators and the security team
Azure DDoS Protection	Network layers, Layer 3 and Layer 4	Microsoft Azure and the Power Pages platform	Traffic floods, protocol attacks, and connection exhaustion	Microsoft platform

6. Common Attack Scenarios

Scenario	Primary control
A large number of devices simultaneously send network traffic	Azure DDoS Protection
One source repeatedly calls an application endpoint	WAF rate limiting
A request contains SQL injection or XSS patterns	WAF managed rules
An automated script submits forms in bulk	CAPTCHA, WAF bot protection, and rate limiting
A user attempts to access an unauthorized Dataverse record	Power Pages table permissions and Dataverse security

7. Recommended Combination for Power Pages

1. Rely on Microsoft’s platform-level Azure DDoS Protection for network-layer attacks.
2. Confirm the WAF status of every production Power Pages website.
3. Enable appropriate WAF managed rules and bot-protection rules.
4. Configure rate limits for critical business endpoints based on normal traffic.
5. Use CAPTCHA appropriately on registration, application submission, and other high-risk forms.
6. Use Power Pages table permissions to protect Dataverse data.
7. Apply server-side business validation in Dataverse instead of relying only on browser JavaScript.
8. Monitor WAF logs, abnormal application volumes, file uploads, and backend workflow activity.

Conclusion

CAPTCHA, WAF, and Azure DDoS Protection protect the user-action, web-application, and network layers respectively. They are not duplicate features and cannot replace one another.

A balanced security design for a public Power Pages website uses Azure DDoS Protection to protect platform availability, WAF to inspect and control web requests, and CAPTCHA to protect critical form operations from automated abuse.

---

This article is based on publicly available Microsoft Power Pages and Azure documentation as of July 2026. Production configuration should also consider organizational security policies, normal traffic patterns, licensing, and business risk.