RFC 9700 / ATTACKS & DEFENSES

In-browser messaging

Browser messaging changes the transport, not the trust rules. A wildcard recipient or unchecked sender can leak or inject a response.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 4.17 ↗

RFC 9700 · § 4.17DEFENSE

3 / 3

Reject a message from any other origin.

Keep transaction binding and the rest of § 2.1 protections in place.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references

WHAT CHANGED

RFC 6749 § 3.1.2RFC 9700 § 4.17.2

In-browser response transports must use exact trusted receiver and sender origins. Wildcard postMessage recipients are prohibited.

Read the updated RFC section ↗

KEY POINT

Verify both ends of the browser message.

Servers MUST exactly match pre-registered receiver origins and send only to trusted client origins. Wildcard target origins MUST NOT be used.
Clients MUST exactly compare the sender origin to the expected authorization-server origin to prevent injection.
All authorization-response protections in § 2.1 still apply to these communication flows.

DETAILS

The RFC covers three failures: wildcard receivers, insufficient receiver-URI validation, and missing sender-origin checks. A string that merely contains a trusted domain is not an exact origin match.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy

All chapters in this RFC