Bug 166624

WebCore::SecurityOrigin has four public create functions: WEBCORE_EXPORT static Ref<SecurityOrigin> create(const URL&); static Ref<SecurityOrigin> createUnique(); WEBCORE_EXPORT static Ref<SecurityOrigin> createFromString(const String&); WEBCORE_EXPORT static Ref<SecurityOrigin> create(const String& protocol, const String& host, std::optional<uint16_t> port); When a WebCore::SecurityOrigin is created using the first function, the port is canonicalized by unsetting it if it matches the default port for a protocol. That is handled by this code in the constructor: if (m_port && isDefaultPortForProtocol(m_port.value(), m_protocol)) m_port = std::nullopt; The second create function is not relevant to this bug. The third function, createFromString, converts a String to a URL and then uses this path. So, for example, the expression SecurityOrigin::createFromString("http://example.com:80").port() would return nullopt, as it would if the port was omitted from the URL string. This is correct as per RFC 6454 because http://example.com and http://example.com:80 have the same security origin. The issue lies with the fourth constructor. It does not perform this canonicalization, allowing two different nonequal SecurityOrigin objects to be created that represent the same security origin. That is, this constructor could be used to create a SecurityOrigin with protocol http, port 80, even though the other constructors would always canonicalize port 80 to nullopt. I noticed this when working on exposing WebKitSecurityOrigin in the GTK+ API. I'm performing the canonicalization at the GTK+ API level for now, but I think it makes sense to do it in WebCore instead. I wonder if changing this in WebCore would expose unexpected side effects.