Put the token in a file and let curl read it, rather than typing it on the command line. curl can read headers from a file with -H @filename, and it can pull a login from a netrc file. Both keep the secret out of your shell history, though the file itself must be protected.
The problem with inline tokens
The easy way to call an API is to paste the header into the command, something like an Authorization header with a bearer value. That line goes into your shell history, shows up in terminal scrollback, and may appear in process listings while it runs. It also gets copied into tickets and chat when someone asks how you made the call.
Option 1: read headers from a file
The curl manual says the --header option can take an argument in @filename style, which adds a header for each line in the input file. Using @- makes curl read the header file from standard input. You can use --header several times.
curl -H @headers.txt https://api.example.com/v1/items
Here headers.txt holds one header per line. Create it with permissions only your user can read, and keep it out of version control. Because the command no longer includes the value, your history stays clean and the line is safe to paste into a bug report.
Option 2: a netrc file
The manual explains that -n or --netrc makes curl scan a netrc file in your home directory for login name and password. If the NETRC environment variable is set, that file name is used, and --netrc-file overrides every other way of choosing the file. The file format is described in netrc(5). The manual also says the netrc file supplies credentials for a hostname regardless of protocol and port.
This suits basic authentication to a host you call often. It does not fit every bearer token API, so the header file is more flexible there.
What curl hides and what it does not
For options that carry a secret, such as a user name and password given on the command line, the manual says that on systems where it works, curl hides the given option argument from process listings. That helps, but it does not remove the text from your shell history. The file based approaches remove it from both places.
| Approach | In shell history | In process list | File to protect |
|---|---|---|---|
| Inline header | Yes | Likely | No |
| Header file with @ | No | No | Yes |
| netrc file | No | No | Yes |
A quick routine
- Create the file with
umask 077set so it is private from the start. - Reference it in the command rather than pasting the value.
- Use a token with narrow scope and an expiry date.
- Never paste real verbose output, because the
-vflag prints request headers. - If a token ever hit your history, revoke it and issue a new one.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Does @filename work with several headers?
The manual says it adds a header for each line in the file.
Does netrc work for bearer tokens?
It is described as a login name and password store. Use a header file for token headers.
Does -v print my token?
Verbose mode prints request headers, so redact them before sharing output. Check your curl version's behaviour.
Sources
Last reviewed: 19 October 2026.
