Verbosity of API responses

1

Some of the API (error) responses are specific enough to allow guessing some internals.

  • /register:
    e.g. curl $API_BASE/register -d username=alice -d givenname= -d surname= -d email= -d password=
    Returns 400 {"code": 402, "message": "ERR402: The username is already registered!"} if the user already exists.
    This one should probably not be directly accessible anyways :slight_smile:

  • /healthz/resolversz:
    Shows name and status of each LDAP and SQL resolver individually.
    Probably same as above, i.e. it should not be directly accessible.

  • /validate/refilltoken:
    e.g. curl $API_BASE/validate/offlinerefill -d refilltoken= -d pass= -d serial=xxx
    Returns 400 {"code": 905, "message": "ERR905: The token does not exist"} if the token does not exist.
    Can be used to guess any token serials.

  • /ttype/tiqr with action=metadata:
    e.g. curl $API_BASE/ttype/tiqr -d action=metadata -d session= -d serial=xxx
    Returns 404 {"code": 601, "message": "The requested token could not be found."} if the TiQR token was not found.
    Can be used to guess TiQR token serials.

  • /container/register/finalize, /container/register/terminate/client, /container/challenge, /container/synchronize, /container/rollover (last one only if policy is set):
    e.g. curl $API_BASE/container/challenge -d scope=user -d container_serial=xxx
    Returns 404 {"code": 601, "message": "Unable to find container with serial xxx."} if container was not found.
    Can be used to guess container serials.

AFAICS just knowing the serials does not present a security vulnerability by itself.

Nonetheless, would you appreciate a PR that adds a container policy at least, to hide the error details?
Similar to this recent PR.