Quand le serveur est en cours d'exécution, un utilisateur mal intentionné ne peut pas interférer dans les communications client/serveur. Néanmoins, quand le serveur est arrêté, un utilisateur local peut usurper le rôle du serveur normal en lançant son propre serveur. Le serveur usurpateur pourrait lire les mots de passe et les requêtes envoyés par les clients, mais ne pourrait pas renvoyer de données car le répertoire PGDATA est toujours sécurisé grâce aux droits d'accès du répertoire. L'usurpation est possible parce que tout utilisateur peut lancer un serveur de bases de données ; un client ne peut pas identifier un serveur invalide sauf s'il est configuré spécialement.

Un moyen d'empêcher les serveurs d'usurper des connexions locales est d'utiliser un répertoire de socket de domaine Unix (unix_socket_directories) qui n'a un droit en écriture que pour un utilisateur local de confiance. Ceci empêche un utilisateur mal intentionné de créer son propre fichier socket dans ce répertoire. Si vous craignez que certaines applications puissent encore référencer /tmp pour le fichier socket et, du coup, être vulnérable au « spoofing », créez un lien symbolique /tmp/.s.PGSQL.5432 pointant vers le fichier socket déplacé. Vous pourriez alors avoir besoin de modifier votre script de nettoyage de /tmp pour empêcher la suppression du lien symbolique.

Une autre option pour les connexions de type local est que les clients utilisent requirepeer pour indiquer un propriétaire précis du processus serveur connecté au socket.

Pour éviter l'usurpation sur les connexions TCP, utilisez des certificats SSL, et assurez-vous que les clients vérifient le certificat du serveur, ou bien utilisez le chiffrage GSSAPI (ou les deux, s'il s'agit de connexions séparées).

Pour éviter l'usurpation avec SSL, le serveur doit être configuré pour accepter les connexions hostssl (Section 20.1) et avoir des fichiers SSL clé et certificat (Section 18.9). Le client TCP doit se connecter en utilisant sslmode='verify-ca' ou verify-full et le fichier certificat racine approprié doit y être installé (Section 32.19.1). Sinon, l'ensemble CA du système peut être utilisé avec sslrootcert=system ; dans ce cas, sslmode=verify-full est forcé pour la sécurité car il est généralement trivial d'obtenir des certificats qui ont été signés par un CA public.

Pour éviter l'usurpation de serveur lors de l'utilisation de l'authentification scram-sha-256 sur un réseau, vous devez vous assurer que vous vous connectez au serveur en utilisant SSL et une des méthodes anti-usurpation décrites dans le paragraphe précédent. De plus, l'implémentation SCRAM dans libpq ne peut pas protéger l'échange entier d'authentification mais, utiliser le paramètre de connexion channel_binding=require atténue le risque d'usurpation du serveur. Un attaquant qui utilise un serveur pour intercepter un échange SCRAM peut utiliser une analyse hors ligne pour déterminer potentiellement le mot de passe haché du client.

Pour éviter l'usurpation avec GSSAPI, le serveur doit être configuré pour n'accepter que les connexions hostgssenc (Section 20.1) et l'authentification gss avec elles. Le client TCP doit se connecter en utilisant gssencmode=require.