URLs and Hashing
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Esta sección contiene especificaciones detalladas de cómo los clientes verifican las URLs.
Canonicalización de URLs
Antes de que se verifiquen las URLs, se espera que el cliente realice alguna canonicalización en esa URL.
Para empezar, suponemos que el cliente analizó la URL y la hizo válida de acuerdo con RFC 2396. Si la URL usa un nombre de dominio internacionalizado (IDN), el cliente debe convertirla a la representación ASCII Punycode. La URL debe incluir un componente de ruta de acceso, es decir, debe tener al menos una barra diagonal después del dominio (http://google.com/ en lugar de http://google.com).
Primero, quita los caracteres de tabulación (0x09), CR (0x0d) y LF (0x0a) de la URL. No quites las secuencias de escape para estos caracteres (p.ej., %0a).
En segundo lugar, si la URL termina en un fragmento, quítalo. Por ejemplo, acorta http://google.com/#frag a http://google.com/.
En tercer lugar, quita los escapes del porcentaje de la URL hasta que no tenga más caracteres en los escapes. (Esto puede hacer que la URL no sea válida).
Para canonizar el nombre de host, haz lo siguiente:
Extrae el nombre de host de la URL y luego haz lo siguiente:
- Quita todos los puntos iniciales y finales.
- Reemplaza los puntos consecutivos por un solo punto.
- Si el nombre de host se puede analizar como una dirección IPv4, normalízalo a 4 valores decimales separados por puntos. El cliente debe controlar cualquier codificación legal de direcciones IP, incluidos los números octal y hexadecimal, y menos de cuatro componentes.
- Si el nombre de host se puede analizar como una dirección IPv6 entre corchetes, normalízalo quitando los ceros iniciales innecesarios de los componentes y contrayendo los componentes cero con la sintaxis de dos dos puntos. Por ejemplo,
[2001:0db8:0000::1] debe transformarse en [2001:db8::1]. Si el nombre de host es uno de los siguientes dos tipos de direcciones IPv6 especiales, transfórmalo a IPv4:
- Una dirección IPv6 asignada a IPv4, como
[::ffff:1.2.3.4], que debe transformarse en 1.2.3.4
- Una dirección NAT64 que usa el prefijo conocido 64:ff9b::/96, como
[64:ff9b::1.2.3.4], que se debe transformar en 1.2.3.4.
- Pon en minúscula toda la string.
Para canonicalizar la ruta de acceso, haz lo siguiente:
- Para resolver las secuencias
/../ y /./ en la ruta de acceso, reemplaza /./ por / y quita /../ junto con el componente de ruta de acceso anterior.
- Reemplaza las ejecuciones de barras consecutivas por un solo carácter de barra.
No apliques estas canonicalizaciones de ruta a los parámetros de búsqueda.
En la URL, usa el carácter de escape de porcentaje para todos los caracteres que son <= ASCII 32, >= 127, # o %. Se deben usar caracteres hexadecimales en mayúsculas en los escapes.
Expresiones de prefijo de ruta de acceso con sufijo de host
Una vez que se canoniza la URL, el siguiente paso es crear las expresiones de sufijo o prefijo. Cada expresión de sufijo o prefijo consta de un sufijo de host (o host completo) y un prefijo de ruta de acceso (o ruta de acceso completa).
El cliente formará hasta 30 combinaciones diferentes de sufijo de host y prefijo de ruta de acceso. Estas combinaciones solo usan los componentes de host y ruta de acceso de la URL. Se descartan el esquema, el nombre de usuario, la contraseña y el puerto. Si la URL incluye parámetros de consulta, al menos una combinación incluirá la ruta completa y los parámetros de consulta.
Para el host, el cliente intentará como máximo con cinco strings diferentes. Son los siguientes:
- Si el nombre de host no es un literal IPv4 o IPv6, se pueden formar hasta cuatro nombres de host que comienzan con el dominio eTLD+1 y agregan componentes iniciales sucesivos. La determinación del eTLD+1 debe basarse en la lista de sufijos públicos. Por ejemplo,
a.b.example.com generaría el dominio eTLD+1 de example.com, así como el host con un componente de host adicional b.example.com.
- Es el nombre de host exacto en la URL. Siguiendo el ejemplo anterior, se verificaría
a.b.example.com.
Para la ruta, el cliente intentará como máximo con seis strings diferentes. Son:
- La ruta exacta de la URL, incluidos los parámetros de búsqueda.
- La ruta exacta de la URL, sin parámetros de búsqueda.
- Las cuatro rutas que se forman a partir de la raíz (/) y que se agregan sucesivamente componentes de ruta, incluida una barra final.
En los siguientes ejemplos, se ilustra el comportamiento de la verificación:
Para la URL http://a.b.com/1/2.html?param=1, el cliente probará estas posibles strings:
a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/
Para la URL http://a.b.c.d.e.f.com/1.html, el cliente probará estas posibles strings:
a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/
(Nota: Omite b.c.d.e.f.com, ya que solo tomaremos los últimos cinco componentes del nombre de host y el nombre de host completo).
Para la URL http://1.2.3.4/1/, el cliente probará estas posibles strings:
1.2.3.4/1/
1.2.3.4/
Para la URL http://example.co.uk/1, el cliente probará estas posibles strings:
example.co.uk/1
example.co.uk/
Hashing
La Navegación segura de Google usa exclusivamente SHA256 como función hash. Esta función hash se debe aplicar a las expresiones anteriores.
El hash completo de 32 bytes, según las circunstancias, se truncará a 4 bytes, 8 bytes o 16 bytes:
Cuando se usa el método hashes.search, actualmente se requiere que los valores hash de la solicitud se truncen a exactamente 4 bytes. El envío de bytes adicionales en esta solicitud comprometerá la privacidad del usuario.
Cuando descargas las listas de la base de datos local con el método hashList.get o el método hashLists.batchGet, la longitud de los hash que envía el servidor se codifica dentro de la convención de nombres de las listas que contienen un sufijo que indica la longitud del hash. Consulta la sección Listas disponibles para obtener más información.
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-07-25 (UTC)
[null,null,["Última actualización: 2025-07-25 (UTC)"],[],[],null,["# URLs and Hashing\n\nThis section contains detailed specifications of how clients check URLs.\n\n### Canonicalization of URLs\n\nBefore any URLs are checked, the client is expected to perform some canonicalization on that URL.\n\nTo begin, we assume that the client has parsed the URL and made it valid according to RFC 2396. If the URL uses an internationalized domain name (IDN), the client should convert the URL to the ASCII Punycode representation. The URL must include a path component; that is, it must have at least one slash following the domain (`http://google.com/` instead of `http://google.com`).\n\nFirst, remove tab (0x09), CR (0x0d), and LF (0x0a) characters from the URL. Do not remove escape sequences for these characters (e.g. `%0a`).\n\nSecond, if the URL ends in a fragment, remove the fragment. For example, shorten `http://google.com/#frag` to `http://google.com/`.\n\nThird, repeatedly percent-unescape the URL until it has no more percent-escapes. (This may render the URL invalid.)\n\n**To canonicalize the hostname:**\n\nExtract the hostname from the URL and then:\n\n1. Remove all leading and trailing dots.\n2. Replace consecutive dots with a single dot.\n3. If the hostname can be parsed as an IPv4 address, normalize it to 4 dot-separated decimal values. The client should handle any legal IP-address encoding, including octal, hex, and fewer than four components.\n4. If the hostname can be parsed as a bracketed IPv6 address, normalize it by removing unnecessary leading zeroes in the components and collapsing zero components by using the double-colon syntax. For example `[2001:0db8:0000::1]` should be transformed into `[2001:db8::1]`. If the hostname is one of the two following special IPv6 address types, transform them into IPv4:\n - An IPv4-mapped IPv6 address, such as `[::ffff:1.2.3.4]`, which should be transformed into `1.2.3.4`;\n - A NAT64 address using [the well-known prefix 64:ff9b::/96](https://datatracker.ietf.org/doc/html/rfc6052#section-2.1), such as `[64:ff9b::1.2.3.4]`, which should be transformed into `1.2.3.4`.\n5. Lowercase the whole string.\n\n**To canonicalize the path:**\n\n1. Resolve the sequences `/../` and `/./` in the path by replacing `/./` with `/`, and removing `/../` along with the preceding path component.\n2. Replace runs of consecutive slashes with a single slash character.\n\nDo not apply these path canonicalizations to the query parameters.\n\nIn the URL, percent-escape all characters that are \\\u003c= ASCII 32, \\\u003e= 127, `#`, or `%`. The escapes should use uppercase hex characters.\n\n### Host-Suffix Path-Prefix Expressions\n\nOnce the URL is canonicalized, the next step is to create the suffix/prefix expressions. Each suffix/prefix expression consists of a host suffix (or full host) and a path prefix (or full path).\n\nThe client will form up to 30 different possible host suffix and path prefix combinations. These combinations use only the host and path components of the URL. The scheme, username, password, and port are discarded. If the URL includes query parameters, then at least one combination will include the full path and query parameters.\n\n**For the host**, the client will try at most five different strings. They are:\n\n- If the hostname is not an IPv4 or IPv6 literal, up to four hostnames formed by starting with the eTLD+1 domain and adding successive leading components. The determination of eTLD+1 should be based on the [Public Suffix List](https://publicsuffix.org/). For example, `a.b.example.com` would result in the eTLD+1 domain of `example.com` as well as the host with one additional host component `b.example.com`.\n- The exact hostname in the URL. Following the previous example, `a.b.example.com` would be checked.\n\n**For the path**, the client will try at most six different strings. They are:\n\n- The exact path of the URL, including query parameters.\n- The exact path of the URL, without query parameters.\n- The four paths formed by starting at the root (/) and successively appending path components, including a trailing slash.\n\nThe following examples illustrate the check behavior:\n\nFor the URL `http://a.b.com/1/2.html?param=1`, the client will try these possible strings: \n\n a.b.com/1/2.html?param=1\n a.b.com/1/2.html\n a.b.com/\n a.b.com/1/\n b.com/1/2.html?param=1\n b.com/1/2.html\n b.com/\n b.com/1/\n\nFor the URL `http://a.b.c.d.e.f.com/1.html`, the client will try these possible strings: \n\n a.b.c.d.e.f.com/1.html\n a.b.c.d.e.f.com/\n c.d.e.f.com/1.html\n c.d.e.f.com/\n d.e.f.com/1.html\n d.e.f.com/\n e.f.com/1.html\n e.f.com/\n f.com/1.html\n f.com/\n\n(Note: skip `b.c.d.e.f.com`, since we'll take only the last five hostname components, and the full hostname.)\n\nFor the URL `http://1.2.3.4/1/`, the client will try these possible strings: \n\n 1.2.3.4/1/\n 1.2.3.4/\n\nFor the URL `http://example.co.uk/1`, the client will try these possible strings: \n\n example.co.uk/1\n example.co.uk/\n\n### Hashing\n\nGoogle Safe Browsing exclusively uses SHA256 as the hash function. This hash function should be applied to the above expressions.\n\nThe full 32-byte hash will, depending on the circumstances, be truncated to 4 bytes, 8 bytes, or 16 bytes:\n\n- When using the [hashes.search method](/safe-browsing/reference/rest/v5/hashes/search), we currently require the hashes in the request to be truncated to exactly 4 bytes. Sending additional bytes in this request will compromise user privacy.\n\n- When downloading the lists for the local database using the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) or the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet), the length of the hashes sent by the server is encoded within the naming convention of the lists that contain suffix indicating hash length. See [Available Lists](/safe-browsing/reference/Local.Database#available-lists) section for more details."]]
