Describe
5.3 Describe REST API security
Aligned to Cisco's 350-401 ENCOR v1.2 exam topics.
On this page
What this objective tests
This is a describe objective. The exam wants clean mental models, not a full configuration. You must explain how automation reaches a network API safely: HTTPS, authentication, authorization, and rate limiting. This matters because scripts act at machine speed. A weak API control fails at machine speed too.
A secure API session answers four questions:
- Is this the real server? Transport Layer Security (TLS) certificate validation.
- Who is the client? Authentication.
- What may the client do? Authorization.
- How much may the client do? Rate limiting.
HTTPS and certificate validation
Always use HTTPS. TLS encrypts the request and the response. The certificate also proves the server identity.
Validation matters as much as encryption. A script that ignores certificate errors accepts any server, including an attacker. Do not disable certificate verification in production automation.
Authentication: basic, tokens, and API keys
| Method | How it works | Use it when |
|---|---|---|
| Basic authentication | Username and password in every request | Labs and simple device APIs |
| Token | Log in once, send the token in a header | Controllers such as Catalyst Center |
| API key | A long-lived secret string per client | Simple service-to-service access |
Tokens and API keys are not the same:
- A token usually comes from a login. It has an expiry time and a scope. It is safer for automation.
- An API key is often static. It lives until someone revokes it. Treat it like a password.
Send a token in a header, not in the URL. URLs appear in logs and history.
curl -sS \
-H "X-Auth-Token: $DNAC_TOKEN" \
-H "Accept: application/json" \
https://dnac.example.com/dna/intent/api/v1/network-deviceThe token comes from an environment variable. It is not hard-coded in the script.
Authorization and RBAC
Authentication proves identity. Role-Based Access Control (RBAC) decides what that identity may do. A read-only role can list devices. An admin role can change them.
Give every script the smallest role that does the job. A reporting script does not need write access.
The status codes tell you which control failed:
| Code | Meaning |
|---|---|
| 401 | Not authenticated. The credential or token is missing, wrong, or expired. |
| 403 | Authenticated but not authorized. The role does not permit this action. |
| 429 | Rate limited. Slow down and retry later. |
Rate limiting
Rate limiting caps how many requests a client may send in a time window. It protects the server from buggy loops and abuse. When a script gets a 429, it must back off and retry with a delay. A script that retries at full speed makes the problem worse.
Secret handling
- Put tokens and keys in environment variables or a vault. Never in source code.
- Rotate long-lived credentials on a schedule.
- Give each script its own credential. One leak does not expose every system.
- Keep tokens out of logs, shell history, and ticket text.
Exam traps
- HTTPS without certificate validation is not enough.
- Authentication is not authorization. 401 and 403 are different failures.
- A token in the URL leaks through logs. Use a header.
- An API key is a secret. Store it like a password.
Pass check
You are ready for this objective when you can do these things:
- Explain the four questions a secure API session answers.
- Explain the difference between a token and an API key.
- Explain the difference between 401, 403, and 429.
- Describe RBAC in one sentence.
- Name two safe places to store a token.