HARBOR DESK / 01 / PRACTICE GUIDE
Secure coding
A request that works is not necessarily authorized. Build trusted actor context, data boundaries, parameterized queries and field allowlists together in Harbor Desk.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
CODE REVIEW DESK
See the decision through the test.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
Who owns the object? / Weak code
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>Boolean(s.ticket)The weak function allows any existing record. The corrected model denies anonymous, other-user and other-tenant requests while retaining the same-tenant owner path. A denial is meaningful only when permitted use still works.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
Separate input from authority
Browser userId, role and tenantId are claims. Derive the actor from a server-validated session and constrain record selection by identity, tenant and object authority together. Ada/north and Ada/south are different principals. Hiding a button improves usability but cannot replace an API authorization decision.
02 / EXPLANATION
Query and output context
The downloadable Python example contrasts SQL concatenation with bound parameters through actual SQLite queries. Parameters prevent input from changing SQL structure; they do not authorize reading another user’s record. The WHERE clause therefore includes owner and tenant. Encode HTML output for its context separately; safe JSON does not imply safe HTML.
03 / EXPLANATION
Bound the change
Spreading a PATCH body into a record can overwrite owner or role. Select allowed fields, validate type and length, and reject unknown fields as the real API fixture does. Read the record again after denial to verify that data and version are unchanged. Java and C# fragments demonstrate query construction; production connection management and error policy need separate design.
04 / EXPLANATION
Worked example: updating a title
In the local server, choose north/ada and read t-1. Record its title and version. Retry as north/ben: expect 404. Although south/ada has the same visible local identifier, it must also be denied t-1 while retaining access to its own t-2. Return to north/ada and send title and version; adding owner must yield 400 without mutation. This separates parameter binding, field allowlisting and object authorization through observable outcomes. Run the SQL fixture only against its synthetic in-memory SQLite database; its four tests cover permitted access, injection, foreign ownership and tenant separation.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.