Python: Harden HttpPlugin request validation

[SergeyMenshykh]

Improve input validation and request handling in the Python HttpPlugin.

Changes

• Add explicit opt-in for unrestricted domain access
• Tighten URL validation logic
• Improve redirect handling when domain restrictions are configured
• Add regression tests

[Copilot]

Pull request overview

This PR hardens the Python HttpPlugin by making outbound HTTP requests opt-in (either via an allowlist of domains or an explicit “allow all domains” switch), tightening URL validation to only permit http/https, and adjusting redirect behavior to reduce SSRF bypass risk.

Changes:

• Change default behavior to block all requests unless allowed_domains is provided or allow_all_domains=True.
• Add scheme validation (only http/https) and disable redirects when domain restrictions are configured.
• Update and expand unit tests to cover the new security behavior and regressions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
python/semantic_kernel/core_plugins/http_plugin.py	Enforces default-deny URL policy, restricts URL schemes, and controls redirect behavior based on domain configuration.
python/tests/unit/core_plugins/test_http_plugin.py	Updates existing tests for the opt-in behavior and adds regression/security tests for default-deny, scheme filtering, and redirect handling.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 88%

✓ Correctness

The PR correctly implements default-deny, scheme validation, and an explicit allow_all_domains opt-in. The redirect-disable logic for domain-restricted configurations is sound. However, the allow_redirects expression in all four HTTP methods contains a vestigial or self.allowed_domains is None clause that carries forward old semantics (where allowed_domains=None meant 'allow all'), contradicting the new default-deny model. While currently unreachable because _validate_url blocks requests first, this expression would incorrectly enable redirects if the deny-all path is ever relaxed.

✓ Security Reliability

This PR is well-designed security hardening for the HttpPlugin. The default-deny posture, scheme validation (blocking file:/, ftp://, etc.), redirect disabling with domain restrictions (SSRF protection), and explicit opt-in for unrestricted access are all sound security improvements. The redirect logic (allow_redirects = self.allow_all_domains or self.allowed_domains is None) is correct across all configuration combinations — in the default case where both are falsy/None, _validate_url blocks before the redirect setting is ever used. No security or reliability issues found.

✓ Test Coverage

The PR adds strong regression tests for the new security defaults (deny-all, scheme blocking, redirect disabling). However, there is an asymetry in redirect-behavior coverage: the 'redirects disabled with allowed_domains' path is verified for all four HTTP methods (GET/POST/PUT/DELETE), but the 'redirects allowed with allow_all_domains=True' path is only verified for GET. Since each method independently computes allow_redirects on a separate line, a typo or copy-paste error in POST/PUT/DELETE would go undetected. This is a non-blocking gap.

✗ Design Approach

The redirect hardening mostly goes in the right direction, but the new flag precedence leaves one SSRF bypass open: when both allowed_domains and allow_all_domains=True are set, the request methods re-enable redirect following even though the class-level security contract says redirects must be disabled whenever allowed_domains is configured.

---

Automated review by SergeyMenshykh's agents

[moonbox3]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
core_plugins
http_plugin.py	57	0	100%
TOTAL	28603	5645	80%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
3913	23 💤	0 ❌	0 🔥	1m 51s ⏱️

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 92% | Result: All clear

Reviewed: Correctness, Security Reliability, Test Coverage, Design Approach

---

Automated review by SergeyMenshykh's agents

[SergeyMenshykh]

Automated Code Review

Reviewers: 4 | Confidence: 88%

✓ Correctness

The PR correctly implements default-deny, scheme validation, and an explicit allow_all_domains opt-in. The redirect-disable logic for domain-restricted configurations is sound. However, the allow_redirects expression in all four HTTP methods contains a vestigial or self.allowed_domains is None clause that carries forward old semantics (where allowed_domains=None meant 'allow all'), contradicting the new default-deny model. While currently unreachable because _validate_url blocks requests first, this expression would incorrectly enable redirects if the deny-all path is ever relaxed.

✓ Security Reliability

This PR is well-designed security hardening for the HttpPlugin. The default-deny posture, scheme validation (blocking file:/, ftp://, etc.), redirect disabling with domain restrictions (SSRF protection), and explicit opt-in for unrestricted access are all sound security improvements. The redirect logic (allow_redirects = self.allow_all_domains or self.allowed_domains is None) is correct across all configuration combinations — in the default case where both are falsy/None, _validate_url blocks before the redirect setting is ever used. No security or reliability issues found.

✓ Test Coverage

The PR adds strong regression tests for the new security defaults (deny-all, scheme blocking, redirect disabling). However, there is an asymetry in redirect-behavior coverage: the 'redirects disabled with allowed_domains' path is verified for all four HTTP methods (GET/POST/PUT/DELETE), but the 'redirects allowed with allow_all_domains=True' path is only verified for GET. Since each method independently computes allow_redirects on a separate line, a typo or copy-paste error in POST/PUT/DELETE would go undetected. This is a non-blocking gap.

✗ Design Approach

The redirect hardening mostly goes in the right direction, but the new flag precedence leaves one SSRF bypass open: when both allowed_domains and allow_all_domains=True are set, the request methods re-enable redirect following even though the class-level security contract says redirects must be disabled whenever allowed_domains is configured.

Automated review by SergeyMenshykh's agents

There are two options for handling the case when both allow_all_domains=True and allowed_domains are set:

Option 1 (current): allow_all_domains=True takes full precedence - requests go to any domain and redirects are allowed. The rationale: if you've explicitly opted into unrestricted access, there's no reason to restrict redirects.
Setting both flags is an unusual configuration, and allow_all_domains is the stronger signal.

Option 2: allowed_domains always disables redirects, even when allow_all_domains=True. The rationale: the presence of allowed_domains means the user cares about domain control, so redirect protection should stay on.

I think option 1 makes more sense - allow_all_domains=True is an explicit "I trust all destinations" declaration, and selectively keeping redirect restrictions contradicts that intent. I've updated the docstring to clearly
document this precedence.

[cherry-bisht]

Hey genuine question. I reported this exact issue (allowed_domains=None allowing all domains by default, inconsistency with the .NET plugin) to MSRC on April 6 , Was this tracked internally from that report, or discovered independently? Just trying to understand how the process works

msrc said the Semantic Kernel Python HttpPlugin offers the ability to restrict the allowed_domains and the decision on which domains should be restricted is left to the user