fix: treat protocol-relative URLs as blocked domains in safe-outputs sanitizer

[Copilot]

sanitizeUrlDomains() was anchored to https:// and sanitizeUrlProtocols() required an explicit scheme, so //evil.com/path passed both filters unchanged. Browsers on HTTPS pages resolve //hostname/path → https://hostname/path, fully bypassing the domain allowlist — including in image embeds where camo proxy requests leak to the attacker.

Changes

• sanitize_content_core.cjs — sanitizeUrlDomains()

  • Extracted shared allowlist logic into inner helper applyDomainFilter(match, hostnameWithPort)
  • Added a second regex pass for protocol-relative URLs using a delimiter-based precondition (^|[\s([{"']) — matches // only at start-of-string or after clear URL delimiters (whitespace, brackets, quotes), avoiding false matches on // inside HTTPS URL paths (e.g. https://github.com//issues); stop-condition (?!\/\/) is symmetric with the existing https:// stop-condition

• sanitize_content.test.cjs

  • New "protocol-relative URL sanitization" describe block with 10 regression tests: plain text, markdown links ([text](//evil.com/path)), image embeds (![](//evil.com/pixel.gif)), allowed domains, subdomains, custom domain env var, mixed content, path+query, redaction logging, and a regression case ensuring https:// URLs with double-slash paths (e.g. https://github.com//issues) are not incorrectly redacted

// Before
sanitizeContentCore('[click](//evil.com/steal)')
// → '[click](//evil.com/steal)'   ← not redacted

// After
sanitizeContentCore('[click](//evil.com/steal)')
// → '[click]((evil.com/redacted)'

[!WARNING]

[Copilot]

Pull request overview

Fixes a sanitizer bypass where protocol-relative URLs (//host/path) were not subject to domain allowlisting, allowing disallowed domains to pass unchanged (including in markdown links/images).

Changes:

• Refactors sanitizeUrlDomains() to share allowlist/redaction logic via an inner helper.
• Adds a second domain-filtering pass to redact protocol-relative URLs (//hostname/...).
• Adds regression tests covering protocol-relative URLs in plain text, markdown links, and image embeds.

Reviewed changes

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

File	Description
actions/setup/js/sanitize_content_core.cjs	Adds protocol-relative URL domain filtering using a second regex pass and shared allowlist logic.
actions/setup/js/sanitize_content.test.cjs	Adds regression tests ensuring protocol-relative URLs are redacted/allowed appropriately and logged.

---

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

[Copilot]

The protocol-relative regex will also match "//" sequences that occur inside the path of an allowed https:// URL (because the lookbehind only excludes ':' and '/'). For example, in "https://github.com//issues", the "//issues" part is preceded by "m" and will be treated as a protocol-relative URL, potentially redacting/altering an otherwise-allowed URL. Consider tightening the precondition so protocol-relative matches only occur at the start of the string or after clear URL delimiters (whitespace, '(', '[', quotes, etc.), rather than after hostname/path characters.

Suggested change

	// The negative lookbehind (?<![:/]) avoids matching the // inside https://.
	// The path stop-condition (?!\/\/) stops before the next protocol-relative URL
	// (analogous to how the httpsUrlRegex stops before the next https:// URL).
	// The path capture group is present for structural symmetry with httpsUrlRegex
	// but is not needed by applyDomainFilter — the full match is used instead.
	const protoRelativeUrlRegex = /(?<![:/])\/\/([\w.-]+(?::\d+)?)(\/(?:(?!\/\/)[^\s,])*)?/gi;
	s = s.replace(protoRelativeUrlRegex, (match, hostnameWithPort) => applyDomainFilter(match, hostnameWithPort));
	// We only treat // as a protocol-relative URL when it appears at the start of
	// the string or immediately after a clear delimiter (whitespace, brackets,
	// or quotes). This avoids matching // segments inside the path of an allowed
	// https:// URL, such as "https://github.com//issues".
	// The path stop-condition (?!\/\/) stops before the next protocol-relative URL
	// (analogous to how the httpsUrlRegex stops before the next https:// URL).
	// Capture groups:
	// 1: prefix (start-of-string or delimiter)
	// 2: full protocol-relative URL (starting with //)
	// 3: hostname (and optional port)
	// 4: optional path
	const protoRelativeUrlRegex = /(^|[\s([{"'])(\/\/([\w.-]+(?::\d+)?)(\/(?:(?!\/\/)[^\s,])*)?)/gi;
	s = s.replace(
	protoRelativeUrlRegex,
	(match, prefix, url, hostnameWithPort) => prefix + applyDomainFilter(url, hostnameWithPort)
	);

[Copilot]

Consider adding a regression test for an allowed https:// URL that contains a double-slash in the path (e.g., "https://github.com//issues") to ensure the new protocol-relative pass doesn’t accidentally treat path "//..." segments as protocol-relative URLs and redact them.

Suggested change

	it("should not treat double slashes in https URL paths as protocol-relative URLs", () => {
	const result = sanitizeContent("https://github.com//issues and //evil.com/path");
	expect(result).toContain("https://github.com//issues");
	expect(result).toContain("(evil.com/redacted)");
	expect(result).not.toContain("//evil.com");
	});

[pelikhan]

@copilot review comments

[pelikhan]

@copilot review comments

[pelikhan]

@copilot review comments

[Copilot]

@copilot review comments

Addressed both review comments in ae6a1b8:

1. Regex tightened (sanitize_content_core.cjs): Replaced the lookbehind (?<![:/]) approach with a delimiter-based match (^|[\s([{"']). The regex now only treats // as a protocol-relative URL at start-of-string or after whitespace/brackets/quotes, preventing false matches on // inside HTTPS URL paths like https://github.com//issues.

2. Regression test added (sanitize_content.test.cjs): Added a test confirming that https://github.com//issues is preserved unchanged while //evil.com/path in the same string is still redacted.

[pelikhan]

@copilot add more positive and negative test cases

[Copilot]

@copilot add more positive and negative test cases

Added 8 more tests in d03fdc8:

Negative (redacted):

• //evil.com:8080/api — port number
• //evil.com/a and //bad.org/b — multiple URLs in one string, all redacted
• src="//evil.com/img.png" — HTML attribute with double-quote delimiter
• //evil.com — hostname only (no path)

Positive (allowed):

• //raw.githubusercontent.com/... with *.githubusercontent.com wildcard domain
• //trusted.net/path with custom GH_AW_ALLOWED_DOMAINS=trusted.net
• {//github.com/repo} — curly-brace delimited context

Boundary (not treated as protocol-relative):

• word//evil.com/path — // not preceded by a delimiter, passes through unchanged