HTTP-based flows can reach blocked services by calling their APIs directly, which weakens connector-based DLP enforcement. They also let makers embed authentication details and sensitive parameters inside step configuration, where they may be visible to others with flow access. That combination creates a hidden path for data movement and secret exposure that administrators may not detect easily.
Why HTTP Calls Break the Connector Boundary
Standard Power Platform connectors are designed around governed, known services, so platform controls can recognise the destination, apply connector-level policy, and give administrators a clearer view of data movement. HTTP-based flows change that pattern because they can call arbitrary endpoints directly. That makes the flow more flexible, but it also creates a less visible path for records, parameters, and responses to move outside the intended connector boundary.
HTTP steps are especially risky when makers use them to work around a blocked connector rather than to extend a sanctioned integration. In practice, the control gap is not that HTTP is inherently unsafe, it is that it can bypass the policy layer that would normally make the integration easier to govern, review, and classify.
Where Leakage Usually Happens in the Flow Definition
The leakage risk is often created at design time, not only at runtime. Authentication headers, API keys, bearer tokens, query strings, and other sensitive parameters may be placed directly in step configuration, test data, or reused expressions. Depending on how the flow is shared and maintained, that material can become visible to people who can inspect or edit the flow even if they should not hold the underlying secret.
Payload handling also matters. When HTTP actions are used to pass data between systems, the flow may expose business records to endpoints that are not covered by the same connector governance model, or it may log enough request and response detail to make sensitive content easier to recover during troubleshooting. For that reason, the risk is not just secret sprawl, it is uncontrolled propagation of data and credentials through the flow itself.
What Administrators Should Treat as the Real Control Problem
The key issue is governance, not syntax. If a flow uses HTTP to reach a service that would otherwise be blocked, administrators should assume the data path is now outside the normal connector decision tree and review it as a separate integration exception. That review should focus on what data is transmitted, what credentials are embedded, who can read the flow definition, and whether the destination is approved for the sensitivity of the data involved.
- Inspect flows that use HTTP actions as potential policy exceptions, not routine integrations.
- Minimise any credential material stored in step configuration and rotate it quickly if exposure is possible.
- Check whether request or response content could reveal customer, operational, or authentication data during support or troubleshooting.
- Prefer connector-managed access where the service is already supported, because it gives better visibility and enforcement.
Risk and Threat Considerations
HTTP-based flows create a hidden exfiltration path when users can send data to endpoints that bypass connector-based DLP controls. The same mechanism can also expose authentication material if secrets are embedded in the action configuration or returned in logs, run history, or shared flow definitions.
Failure mechanism: A maker uses a direct HTTP step to talk to an ungoverned endpoint, then hardcodes or passes through tokens, keys, or sensitive parameters in the request so the flow can authenticate or shape the call.
Impact: Sensitive records, credentials, or API access can be copied into a less visible path, making unauthorised movement, reuse, or disclosure harder for administrators to detect and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | HTTP steps can embed API keys and tokens directly in flow configuration. |
| NHI-03 — Visibility and Monitoring | Direct HTTP paths can bypass normal connector visibility and hide data movement. | |
| Recommendation — Store flow credentials outside step definitions and rotate exposed secrets quickly. Monitor direct HTTP integrations separately from governed connector activity. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Shared flows can expose embedded credentials and data to users with flow access. |
| 3.4 — Secure Configuration of Enterprise Assets and Software | HTTP-based integrations often depend on configurable endpoints and secrets that need hardening. | |
| Recommendation — Restrict who can inspect, edit, and export flows that carry sensitive parameters. Harden flow configurations so secrets and endpoints are not left in editable plaintext fields. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Least Privilege | Direct HTTP access can widen who and what can move data beyond intended connector controls. |
| DE.CM-1 — Anomalies and Events Detected | Unusual direct HTTP traffic in flows should be detectable as a policy exception. | |
| GV.PO-1 — Policy | The scenario is fundamentally about enforcing policy boundaries around sanctioned integrations. | |
| Recommendation — Apply least-privilege access to flow authorship and to the data paths they can invoke. Detect and review direct HTTP calls that create data paths outside normal connector governance. Define policy that distinguishes approved connectors from exception-based HTTP integrations. | ||
Practitioner Guidance
What to verify: Treat every HTTP-based flow as a review item for destination, authentication material, and data classification. If the flow carries production data or long-lived secrets, confirm who can view the definition and whether the request can be reconstructed from run history or environment access.
Decision rule: If the flow exists only because a needed connector is blocked, decide whether the exception should be approved, replaced with a governed integration, or redesigned so the sensitive data never passes through the flow in plaintext or editable parameters.
Practitioner takeaway: The control question is not whether HTTP works, it is whether the organisation can still see, restrict, and revoke the data path once HTTP is used to leave the connector model.
Related resources from NHI Mgmt Group
- Why do fragmented and derivative data create a bigger insider risk problem than classic file-based leakage?
- How should security teams reduce cross-tenant risk when using Power Platform HTTP connectors?
- Why do custom connectors create more risk than prebuilt connectors in Power Platform environments?
- Why do Power Platform DLP controls create residual risk in organisations with many citizen-built apps and flows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
