Enquanto o servidor está em execução, não é possível que um usuário mal-intencionado substitua o servidor de banco de dados normal por outro falso. Entretanto, quando o servidor está inativo, é possível que um usuário local falsifique o servidor normal iniciando seu próprio servidor. O servidor falso pode ler senhas e consultas enviadas por clientes, mas não pode retornar nenhum dado, porque o diretório PGDATA ainda estaria seguro devido às permissões do diretório. A falsificação é possível, porque qualquer usuário pode iniciar um servidor de banco de dados; o cliente não pode identificar um servidor falso, a menos que esteja configurado de forma especial.

Uma maneira de evitar a falsificação de conexões no modo local, é usar um diretório de soquete de domínio Unix (unix_socket_directories), que tenha permissão de escrita apenas para usuário local confiável. Isto impede que um usuário mal-intencionado crie seu próprio arquivo de soquete neste diretório. Havendo preocupação com o fato de algumas aplicações ainda fazerem referência a /tmp para o arquivo de soquete, portanto, ficando vulneráveis à falsificação, durante a inicialização do sistema operacional deve ser criada a ligação simbólica /tmp/.s.PGSQL.5432 apontando para o arquivo de soquete realocado. Também pode ser necessário modificar o script de limpeza de /tmp, para evitar a remoção dessa ligação simbólica.

Outra opção para conexões do tipo local, seria os clientes usarem requirepeer para especificar o dono do processo servidor conectado ao soquete.

Para evitar falsificação em conexões TCP, devem ser usados certificados SSL, e assegurado que os clientes verifiquem o certificado do servidor, ou usada a encriptação GSSAPI (ou ambos, se estiverem em conexões separadas).

Para evitar falsificação usando SSL, o servidor deve ser configurado aceitando apenas conexões hostssl (veja pg_hba.conf), e ter arquivos de chave e certificado SSL (veja Conexões TCP/IP seguras com SSL). O cliente TCP deve se conectar usando sslmode=verify-ca, ou verify-full, e ter o arquivo de certificado raiz apropriado instalado (veja Seção 32.19.1). Como alternativa, pode ser usado o system CA pool, conforme definido pela implementação do SSL, usando sslrootcert=system; neste caso, usar sslmode=verify-full é obrigatório por questões de segurança, uma vez que geralmente é fácil obter certificados assinados por uma CA pública.

Para evitar a falsificação de servidor ao usar a autenticação por senha scram-sha-256 em uma rede, deve-se garantir a conexão com o servidor seja feita usando SSL e um dos métodos de prevenção de falsificação descritos no parágrafo anterior. Além disso, a implementação do SCRAM na libpq não consegue proteger todo o intercâmbio de autenticação, mas o uso do parâmetro de conexão channel_binding=require oferece uma mitigação contra a falsificação de servidor. Um atacante que utiliza um servidor malicioso para interceptar uma troca SCRAM pode empregar análise fora-de-linha para, potencialmente, determinar a senha com hash do cliente.

Para evitar falsificação com GSSAPI, o servidor deve ser configurado aceitando somente conexões hostgssenc (veja pg_hba.conf) e usar a autenticação gss. O cliente TCP deve se conectar usando gssencmode=require.