URLs and Hashing
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette section contient des spécifications détaillées sur la façon dont les clients vérifient les URL.
Choix de l'URL canonique
Avant que des URL ne soient vérifiées, le client doit effectuer une canonique de l'URL.
Pour commencer, nous supposons que le client a analysé l'URL et l'a validée conformément à la norme RFC 2396. Si l'URL utilise un nom de domaine internationalisé (IDN), le client doit convertir l'URL en une syntaxe Punycode ASCII. L'URL doit inclure un composant de chemin, c'est-à-dire qu'elle doit comporter au moins une barre oblique après le domaine (http://google.com/ au lieu de http://google.com).
Tout d'abord, supprimez les caractères de tabulation (0x09), CR (0x0d) et LF (0x0a) de l'URL. Ne supprimez pas les séquences d'échappement de ces caractères (par exemple, %0a).
Ensuite, si l'URL se termine par un fragment, supprimez-le. Par exemple, raccourcissez http://google.com/#frag en http://google.com/.
Enfin, supprimez les échappements de pourcentage de l'URL jusqu'à ce qu'il n'y en ait plus. (ce qui peut rendre l'URL non valide).
Pour mettre en forme canonique le nom d'hôte:
Extrayez le nom d'hôte de l'URL, puis procédez comme suit :
- Supprimez tous les points au début et à la fin.
- Remplacez les points consécutifs par un seul point.
- Si le nom d'hôte peut être analysé en tant qu'adresse IPv4, normalisez-le en y indiquant 4 valeurs décimales séparées par des points. Le client doit gérer tout encodage d'adresse IP légitime, y compris les valeurs octales, hexadécimales et moins de quatre composants.
- Si le nom d'hôte peut être analysé en tant qu'adresse IPv6 entre crochets, normalisez-le en supprimant les zéros inutiles au début des composants et en réduisant les composants à zéro à l'aide de la syntaxe à double deux-points. Par exemple,
[2001:0db8:0000::1] doit être transformé en [2001:db8::1]. Si le nom d'hôte correspond à l'un des deux types d'adresses IPv6 spéciaux suivants, transformez-le en IPv4 :
- Une adresse IPv6 mappée sur IPv4, telle que
[::ffff:1.2.3.4], qui doit être transformée en 1.2.3.4 ;
- Une adresse NAT64 utilisant le préfixe bien connu 64:ff9b::/96, comme
[64:ff9b::1.2.3.4], qui doit être transformée en 1.2.3.4.
- Mettre la chaîne en minuscules.
Pour mettre en forme canonique le chemin:
- Corrigez les séquences
/../ et /./ du chemin en remplaçant /./ par / et en supprimant /../ avec le composant de chemin précédent.
- Remplacez les séries de barres obliques consécutives par une seule barre oblique.
N'appliquez pas ces méthodes de mise en forme canonique du chemin aux paramètres de requête.
Dans l'URL, appliquez des échappements de pourcentage à tous les caractères qui sont : <= ASCII 32, >= 127, # ou %. Les échappements doivent utiliser des caractères hexadécimaux en majuscules.
Expressions de suffixe d'hôte et de préfixe de chemin
Une fois l'URL mise en forme canonique, l'étape suivante consiste à créer les expressions de suffixe/préfixe. Chaque expression de suffixe/préfixe se compose d'un suffixe d'hôte (ou hôte complet) et d'un préfixe de chemin (ou chemin d'accès complet).
Le client formera jusqu'à 30 combinaisons possibles de suffixe d'hôte et de préfixe de chemin. Ces combinaisons n'utilisent que les composants d'hôte et de chemin de l'URL. Le schéma, le nom d'utilisateur, le mot de passe et le port sont supprimés. Si l'URL inclut des paramètres de requête, au moins une combinaison inclut le chemin complet et les paramètres de requête.
Pour l'hôte, le client essaie au maximum cinq chaînes différentes. Les voici :
- Si le nom d'hôte n'est pas un littéral IPv4 ou IPv6, jusqu'à quatre noms d'hôte peuvent être créés en commençant par le domaine eTLD+1 et en ajoutant des composants au début. La détermination de l'eTLD+1 doit être basée sur la liste des suffixes publics. Par exemple,
a.b.example.com générerait le domaine eTLD+1 de example.com ainsi que l'hôte avec un composant d'hôte supplémentaire b.example.com.
- Le nom d'hôte exact dans l'URL. Dans l'exemple précédent,
a.b.example.com serait vérifié.
Pour le chemin, le client essaie au maximum six chaînes différentes. À savoir :
- Le chemin d'accès exact de l'URL, y compris les paramètres de requête.
- Le chemin d'accès exact de l'URL, sans paramètres de requête.
- Les quatre chemins créés en partant de la racine (/) et en ajoutant successivement les composants de chemin, y compris une barre oblique finale.
Les exemples suivants illustrent le comportement de la vérification :
Pour l'URL http://a.b.com/1/2.html?param=1, le client essaie les chaînes possibles suivantes :
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/
Pour l'URL http://a.b.c.d.e.f.com/1.html, le client essaie les chaînes possibles suivantes :
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/
(Remarque: ignorez b.c.d.e.f.com, car nous ne prendrons que les cinq derniers composants du nom d'hôte et le nom d'hôte complet.)
Pour l'URL http://1.2.3.4/1/, le client essaie les chaînes possibles suivantes :
1.2.3.4/1/
1.2.3.4/
Pour l'URL http://example.co.uk/1, le client essaie les chaînes possibles suivantes :
example.co.uk/1
example.co.uk/
Hachage
La navigation sécurisée Google utilise exclusivement SHA256 comme fonction de hachage. Cette fonction de hachage doit être appliquée aux expressions ci-dessus.
Le hachage complet de 32 octets sera tronqué en 4 octets, 8 octets ou 16 octets, selon les circonstances:
Lorsque vous utilisez la méthode hashes.search, nous exigeons actuellement que les hachages de la requête soient tronqués à exactement quatre octets. L'envoi d'octets supplémentaires dans cette requête compromet la confidentialité des utilisateurs.
Lorsque vous téléchargez les listes pour la base de données locale à l'aide de la méthode hashList.get ou de la méthode hashLists.batchGet, la longueur des hachages envoyés par le serveur est encodée dans la convention d'attribution de noms des listes contenant un suffixe indiquant la longueur du hachage. Pour en savoir plus, consultez la section Listes disponibles.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[null,null,["Dernière mise à jour le 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."]]
