---
# System prepended metadata

title: Pulp API Returning Secrets in API

---

# Pulp API Returning Secrets in API

## The Concern

Pulp's secrets are sent back to users via the API. These are secrets Pulp presents to remote servers, e.g:

* username and password for basic authentication
* proxy_username and proxy_password - used for proxy authentication
* client_key - used for client authentication to remotes
* headers - sometimes used for authentication

The concern is that re-presenting these credentials is a risk that lowers the security Pulp users experience.

## Reasons it is this way

Removing them from the API doesn't protect them in practice as any user with the write permission can easily steal them by: Update the url to a server they control and sync. The credentials will be submitted to them.

By default, Pulp's authorization system assigns read and writer permissions together, but a customized rbac on some systems could assign a read permission to some users/groups without assigning the write permission.


## Things we tried

### Idea: Redact the data with *****.

This didn't work out as the bindings and integrators use PUT calls, when we modify data and return it they submit it back to us and accidentally change their password to *****. This happened several times in practice.

### Idea: Just omit the secrets in responses.

This didn't work because the openAPI schema didn't adequately describe these fields as something you can write, but can never read. This caused our bindings to be incorrect.
