Security by Design

Building a tool that touches real network infrastructure while also working as a cybersecurity professional creates a particular kind of pressure: I couldn't let myself treat security as a checklist item to bolt on before release. It had to be a design constraint present in every decision, the same way performance or usability would be for someone else's product. This post pulls together the security posture that runs underneath everything covered so far in this series.

Least privilege, applied to a mobile app

The proxy architecture from Part 2 is the foundation, but least privilege runs deeper than "the app doesn't hold the token." Every piece of the system is scoped to the smallest set of permissions it actually needs to do its job. The mobile app authenticates as a specific user with a specific, limited session, not as an all-access administrator. The edge function's path allowlist doesn't just prevent reaching unapproved endpoints; it's reviewed and narrowed over time as I confirm which specific operations the app genuinely uses, rather than left broad "just in case" a future feature needs it.

Every piece of the system is scoped to the smallest set of permissions it actually needs, reviewed and narrowed over time, not left broad just in case.

This same instinct shaped how write actions were introduced. Read operations, checking status, viewing metrics, carry low risk if something goes wrong. Write operations, renaming a device, restarting an AP, carry real operational risk, and each one was added deliberately and individually, with its own validation and its own place on the allowlist, rather than opening up a broad category of "device management" actions all at once.

Encryption at rest, and why the key never lives near the code

As covered in Part 2, the Mist API token is encrypted at rest using AES-256-GCM before it ever touches the database, and decrypted only transiently, inside the edge function, for the span of a single outbound request. The encryption key itself is stored in the platform's function-level environment configuration: never committed to source control, never hardcoded, and never passed through any layer of the app that doesn't strictly need it. Separating the key from the code that uses it, and the code from the data it protects, means that no single leak, a repository exposure, a database dump, a compromised client, is enough on its own to expose a usable credential.

Redaction as a working habit, not just a policy

Working with real infrastructure data during development means constantly handling things that should never appear in a screenshot, a log, or a shared file: subnet layouts, VLAN assignments, RADIUS secrets, WLAN passphrases, organization and site identifiers. Building good redaction habits into the development process itself, treating every screenshot, every exported config, every debug log as something that needs a pass before it leaves a secure environment, became as routine as the API-testing discipline from Part 3.

This matters just as much for this blog series as it did during development. Anywhere in this series I reference a real screenshot of the MistPulse UI as inspiration for an image, the guidance is the same: blur or redact anything that could identify a real organization, site, device, or credential before it's used publicly. A tool built to take infrastructure security seriously should be documented the same way.

• Encrypt sensitive values at rest, and keep the encryption key outside both the code and the data it protects
• Scope every credential and session to the minimum access it needs, and re-narrow that scope over time
• Treat screenshots and exported configs from real environments as sensitive by default: redact before sharing
• Add write actions individually and deliberately, never as a broad, general-purpose capability

Security review as a recurring practice, not a one-time gate

The bug-and-security sweep habit from Part 4 deserves a second mention here, because it's really the operational half of this security posture. Architecture and encryption set the boundaries; the recurring review is what confirms those boundaries are still holding as the codebase grows. A security posture that's correct on day one and never re-checked tends to erode quietly as new features get added: a slightly too-permissive regex here, a validation rule that got skipped there. Treating security review as a recurring practice, tied to every deployment rather than a single audit early in the project, is what's kept that erosion from happening.

This posture was put to a real test not long ago, when Juniper announced a change to one of the exact API endpoints MistPulse depends on. It's one thing to design a secure architecture in the abstract. It's another to migrate a live feature to a new endpoint, under a real deadline, without breaking anything for real usage or cutting a corner on the discipline that got the project this far. That story is next.

Coming up next: When APIs Change Under You: the real SLE endpoint deprecation, and how the "curl first" methodology carried the migration