PGPASSWORD is an environment variable used to supply a PostgreSQL password to client tools without interactive entry. It is commonly read by utilities such as psql and pg_dump, which means the secret can be exposed through process listings, shell history, logs, or inherited environments if handled carelessly.
How PGPASSWORD works
PGPASSWORD is a convenient way to pass a PostgreSQL password to command-line client tools, but it is only a transport mechanism for a secret, not a security control. It affects how authentication material reaches the client process, not whether the password is strong, protected, or appropriate for long-term use.
Because it is read by tools such as psql and pg_dump, the variable can be inherited by child processes and exposed wherever process state is observable. That makes its use materially different from prompting interactively or using a protected credential store.
Why PGPASSWORD is sensitive
The risk is not the variable itself, but the fact that it can carry a reusable password into places where other software, operators, or logs may see it. Environment variables are often easier to leak than teams expect, especially in shell sessions, wrapper scripts, CI jobs, and debugging output.
Any secret delivered through the environment should be treated as potentially recoverable by a local user with process visibility, by automated tooling that captures runtime state, or by later commands that dump inherited variables. The safer the surrounding environment, the lower the exposure, but the mechanism still creates avoidable secret sprawl.
Safer ways to supply PostgreSQL credentials
For manual administration, interactive password prompts reduce accidental disclosure because the secret is not stored in the shell environment. For repeated or automated access, a protected secret store or a PostgreSQL password file is usually a better pattern than embedding credentials in process state.
Good practice is to keep the secret out of command history, out of scripts where possible, and out of broad inheritance chains. When automation must run non-interactively, the real goal is to minimise where the secret exists, how long it exists, and which processes can observe it.
Operational handling and troubleshooting
When PGPASSWORD is used, treat it as a temporary convenience with a narrow scope. Set it only for the command that needs it, avoid exporting it globally in long-lived shells, and review wrapper scripts that may echo, log, or forward the environment unintentionally.
If a password appears in process listings, shell history, CI logs, or inherited environment snapshots, assume it has crossed a trust boundary and should no longer be considered private. For that reason, PGPASSWORD should be reserved for tightly controlled use cases, not as a default credential delivery pattern.
Risk and Threat Considerations
PGPASSWORD creates exposure when a password is placed in a process environment that other commands, log collectors, or local users may inspect. The danger is secret disclosure, followed by reuse of the password against PostgreSQL or any other system where the same credential is accepted.
Failure mechanism: the password is inherited by child processes or recorded in operational artefacts such as process metadata, history files, or logs, allowing an attacker or careless operator to recover it without needing to break the database itself.
Impact: disclosed credentials can enable unauthorized database access, data extraction, privilege abuse, or reuse of the same secret elsewhere if password reuse exists.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PGPASSWORD carries a reusable password that must be protected across its lifecycle. |
| AC-6 — Least Privilege | Using a password in the environment can widen access if the secret is visible to other processes. | |
| Recommendation — Manage database passwords as authenticators, and limit their storage, exposure, and reuse. Restrict who and what can access credentials and related runtime environment data. | ||
| CIS Controls v8 | CIS-5 — Account Management | PGPASSWORD is an account credential handling concern that affects how access is provisioned and used. |
| Recommendation — Use controlled credential handling for accounts and avoid exposing passwords in process state. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The term directly concerns secret exposure through environment variables and process state. |
| NHI-07 — Long-Lived Secrets | PGPASSWORD is dangerous when it carries a password that persists beyond a single command. | |
| Recommendation — Keep passwords out of logs, histories, and inherited environments. Replace long-lived runtime secrets with shorter-lived or better-contained credential patterns. | ||
Practitioner Guidance
Why practitioners should care: the main decision is not whether PGPASSWORD is convenient, but whether the convenience justifies exposing a reusable secret to the runtime environment. If the answer is no, use a method that keeps the password out of visible process state.
Common misunderstanding: many teams treat environment variables as private because they are not typed on screen. In practice, they are often easier to leak than interactive entry, especially in shared shells and automation contexts.
Practitioner takeaway: prefer PGPASSWORD only when the environment is tightly controlled and the secret is truly short-lived; otherwise, choose a credential delivery method with a smaller disclosure surface.