5.3 Describe REST API security

REST APIs are part of modern network operations. ENCOR does not expect you to become an application security engineer, but you should know what makes an API call safe enough for network automation.

The core idea

A secure REST API session should answer these questions:

1. Is this the real server? TLS certificate validation.
2. Who is the client? Authentication.
3. What is the client allowed to do? Authorization.
4. Is the secret protected? Token and credential handling.
5. Can the action be traced? Logging and accountability.

Automation script | v HTTPS + cert validation -> bad cert? STOP | v Auth (token/basic) -> 401? fix credentials | v API request -> 403? fix role/scope | v Parse JSON response -> 4xx/5xx? read error body

Minimum safe pattern

Use HTTPS, validate certificates, authenticate, use least privilege, set timeouts, and handle errors.

import os
import requests

BASE_URL = "https://dnac.example.com"
TOKEN = os.environ["DNAC_TOKEN"]

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/json",
}

response = requests.get(
    f"{BASE_URL}/dna/intent/api/v1/network-device",
    headers=headers,
    timeout=10,
)

response.raise_for_status()
for device in response.json().get("response", []):
    print(device.get("hostname"), device.get("managementIpAddress"))

Important choices:

• The token comes from an environment variable, not hard-coded source.
• HTTPS is used.
• Certificate verification is left enabled. Do not use verify=False in real automation.
• A timeout prevents the script from hanging forever.
• raise_for_status() fails loudly on HTTP errors.

Curl example

curl -sS \
  -H "Authorization: Bearer $DNAC_TOKEN" \
  -H "Accept: application/json" \
  https://dnac.example.com/dna/intent/api/v1/network-device

For RESTCONF in a lab, you may see basic authentication:

curl -sS \
  -u "$RESTCONF_USER:$RESTCONF_PASSWORD" \
  -H "Accept: application/yang-data+json" \
  https://router1.example.com/restconf/data/ietf-interfaces:interfaces

In production, prefer role-scoped credentials or tokens, restrict source access, and protect secrets.

Authentication versus authorization

Authentication proves identity. Authorization controls permissions.

A script that can read inventory should not automatically be able to push device configuration. A token used for reporting should be read-only. A token used for change automation should be scoped, logged, rotated, and protected.

HTTP status codes you should recognize

Lab

Goal: Make a safe authenticated API call.

Tasks:

1. Store a token or password in an environment variable.
2. Call a read-only API endpoint over HTTPS.
3. Leave TLS verification enabled.
4. Add a timeout.
5. Print only non-sensitive fields.
6. Test a bad token and observe 401 or 403.
7. Test a malformed URL or payload and observe the error handling.

Success criteria:

• No secrets appear in source code, shell history output, or logs.
• The script fails clearly on authentication/authorization errors.
• The script does not disable certificate verification.
• The API account has only the permission needed for the task.

Exam traps

• HTTPS without certificate validation is not enough.
• Authentication is not authorization.
• A token is a secret. Treat it like a password.
• 401 and 403 are different: unauthenticated versus not allowed.
• Hard-coding credentials in scripts is a security failure and an operations failure.