Add Kestrel security considerations article#37328
Open
BrennanConroy wants to merge 2 commits into
Open
Conversation
Publish a new Learn article covering Kestrel's security considerations, configurable limits, and request-parsing behavior, and add a TOC entry under the Kestrel node. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Spell out 'and' in section headings (replacing '&' and '/') so the OPS-generated bookmarks use clean single-dash anchors, and update the in-page links to match. Resolves the bookmark-not-found build warnings. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
wadepickett
reviewed
Jul 10, 2026
|
|
||
| - Chunk format: `chunk-size [chunk-ext] CRLF chunk-data CRLF` | ||
| - Maximum chunk prefix length: 10 bytes (supports chunk sizes up to `0x7FFFFFFF`) | ||
| - Chunk extensions are validated—unpaired `\r` or `\n` in extensions cause rejection |
Contributor
There was a problem hiding this comment.
Suggested change
| - Chunk extensions are validated—unpaired `\r` or `\n` in extensions cause rejection | |
| - Chunk extensions are validated—unpaired `\r` or `\n` in extensions cause rejection. |
Very minor: Complete sentence, so added a period per style guilde.
wadepickett
reviewed
Jul 10, 2026
| ### Request line validation | ||
|
|
||
| - **Method**: Only valid HTTP token characters are accepted. Invalid token characters in the method cause rejection. | ||
| - **Request target**: Empty paths and paths starting with `?` or `%` are rejected. Null bytes (`0x00`) are rejected because they can cause issues with native servers when forwarded; non-ASCII bytes (>= `0x80`) are rejected during ASCII string conversion. Kestrel's parser scans for delimiters to find target boundaries but doesn't perform a per-byte VCHAR check (RFC 9112 §4), so bytes in `0x01–0x1F` (excluding `\0`, `\n`, `\r`, space) and `0x7F` (DEL) reach `Request.Path` unchanged. The practical risk is log injection—for example, `0x1B` (ESC) in the path can inject ANSI escape sequences into log viewers. Applications can defend by deploying behind a stricter reverse proxy, using a logger provider that escapes control characters, sanitizing logs before displaying them by escaping control characters. |
Contributor
There was a problem hiding this comment.
Suggested change
| - **Request target**: Empty paths and paths starting with `?` or `%` are rejected. Null bytes (`0x00`) are rejected because they can cause issues with native servers when forwarded; non-ASCII bytes (>= `0x80`) are rejected during ASCII string conversion. Kestrel's parser scans for delimiters to find target boundaries but doesn't perform a per-byte VCHAR check (RFC 9112 §4), so bytes in `0x01–0x1F` (excluding `\0`, `\n`, `\r`, space) and `0x7F` (DEL) reach `Request.Path` unchanged. The practical risk is log injection—for example, `0x1B` (ESC) in the path can inject ANSI escape sequences into log viewers. Applications can defend by deploying behind a stricter reverse proxy, using a logger provider that escapes control characters, sanitizing logs before displaying them by escaping control characters. | |
| - **Request target**: Empty paths and paths starting with `?` or `%` are rejected. Null bytes (`0x00`) are rejected because they can cause issues with native servers when forwarded; non-ASCII bytes (>= `0x80`) are rejected during ASCII string conversion. Kestrel's parser scans for delimiters to find target boundaries but doesn't perform a per-byte VCHAR check (RFC 9112 §4), so bytes in `0x01–0x1F` (excluding `\0`, `\n`, `\r`, space) and `0x7F` (DEL) reach `Request.Path` unchanged. The practical risk is log injection—for example, `0x1B` (ESC) in the path can inject ANSI escape sequences into log viewers. Applications can defend against this with one or more of the following measures: deploying behind a stricter reverse proxy, using a logger provider that escapes control characters, or sanitizing logs before they're displayed. |
Is this meant to be one or more?
wadepickett
approved these changes
Jul 10, 2026
wadepickett
left a comment
Contributor
There was a problem hiding this comment.
Looks great! Approved. See my two suggestions inline.
Contributor
|
@tdykstra, watch in case any timely review merge help needed, since I am not available for a week starting today. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Kestrel has a large surface of security-relevant behaviors, configurable limits, and request-parsing decisions that weren't documented anywhere. This publishes that guidance as a proper Learn article so application developers configuring Kestrel in production and security auditors reviewing its threat surface have a single reference.
What
aspnetcore/fundamentals/servers/kestrel/security-considerations.md, a new article covering trust boundaries and reverse-proxy topologies, transport security (TLS/mTLS), HTTP/1.1, HTTP/2, and HTTP/3 limits, request smuggling and parsing validation, forwarded headers, host filtering, rate limiting, WebSockets, named pipes, monitoring/metrics, and a production security checklist.aspnetcore/toc.yml.Notes for reviewers
<xref:...>cross-references to avoid fabricating unverified API doc IDs, per the repo's guidance. These can be linked later once IDs are confirmed.not-latest-version-without-not-supported-content.mdinclude, which is the required variant for articles targeting>= aspnetcore-8.0.monikerRangeis set to>= aspnetcore-8.0; adjust if a different lower bound is preferred.This content is AI-assisted (
ai-usage: ai-assistedin frontmatter).Internal previews