サーバが稼働中、悪意のあるユーザが通常のデータベースサーバに取って代わることはできません。 しかし、サーバが停止している時、ローカルユーザに対し、独自のサーバを起動させることで正常なサーバになりすますことは可能です。 なりすましたサーバで、クライアントから送信されたパスワードを読み取ることも問い合わせを読み取ることも可能です。 しかし、PGDATAディレクトリの安全性はディレクトリの権限により維持されていますので、データを返すことはできません。 誰もがデータベースサーバを起動させることができるため、なりすましは可能です。 特殊な設定がなされていなければ、クライアントは無効なサーバであることを識別できません。

local接続に対してなりすましを防ぐ、ひとつの方法は、信頼できるローカルユーザのみに書き込み権限を付与したUnixドメインソケットディレクトリ（unix_socket_directories）を使用することです。 これにより、悪意のあるユーザがそのディレクトリに独自のソケットを作成することを防ぐことができます。 一部のアプリケーションがソケットファイルのために/tmpを参照し、なりすましに対して脆弱であるかもしれないと気にするならば、オペレーティングシステムの起動時に、再割り当てされたソケットファイルを指し示す/tmp/.s.PGSQL.5432というシンボリックリンクを作成してください。 また、このシンボリックリンクが削除されることを防ぐために、/tmpを整理するスクリプトを変更する必要があるかもしれません。

local接続についての別の選択肢は、クライアントがrequirepeerを使用して、ソケットに接続しているサーバプロセスの必要な所有者を指定することです。

TCP接続のなりすましを防ぐためには、SSL証明書を使用してクライアントにサーバの証明書を確実に検査させるか、GSSAPI暗号化を使用します。 （あるいはそれらが別々の接続上にあるなら、その両方を使います。）

SSLでなりすましを防ぐためには、サーバはhostssl接続（21.1）のみを受け付け、SSLキーと証明書ファイル（19.9）を持つ必要があります。 TCPクライアントはsslmode=verify-caもしくはverify-fullを使用して接続し、また、適切なルート証明書ファイルをインストールしなければなりません（34.19.1）。 あるいは、sslrootcert=systemを使用してシステムCAプールを使用できます。この場合、sslmode=verify-fullが安全のために強制されます。これは、一般的に公開CAによって署名された証明書を取得するのが簡単なためです。

ネットワーク経由でscram-sha-256パスワード認証を使用する場合にサーバのなりすましが発生しないようにするには、SSLを使用してサーバに接続し、前の段落で説明したなりすまし防止方法の1つを使用する必要があります。 さらに、libpqのSCRAM実装は認証情報の交換全体を保護できませんが、channel_binding=require接続パラメータを使用すると、サーバのなりすましに対する防御が提供されます。 不正なサーバを使用してSCRAM交換を傍受する攻撃者は、オフライン分析を使用して、クライアントからのハッシュ化されたパスワードを判断できる可能性があります。

GSSAPIでなりすましを防ぐためには、サーバはhostgssenc接続（21.1）のみを受け付け、gss認証をその接続で使います。 TCPクライアントはgssencmode=requireを使用して接続しなければなりません。