Security belongs in application design because individually permitted actions can combine into an unauthorized business result. Authentication and a successful screen-level permission check do not establish that shared limits, lifecycle rules, or trusted evidence remain intact across concurrent requests and background processing.
For a product owner commissioning a replacement-authorization service, the immediate decision is how the application protects an approved unit entitlement across every channel that can consume it. The system must distinguish a person’s permission to submit a request from the remaining entitlement available to that request.
A late test may expose a weak limit check, but fixing it can require a different transaction boundary, data model, or integration contract. Security design should therefore begin with the business condition that must remain true and the evidence needed to enforce it.
Define the invariant that protects the business
An invariant is a condition the application must preserve. In this example, the total active replacement allocations against an approved entitlement must not exceed its permitted quantity. The precise treatment of cancellations, reservations, expiry, and completed fulfillment must be defined by the business owner.
Identify the protected facts: the original entitlement, its approved quantity, any authorized adjustments, current allocations, and the identity of each request. Record which component owns each fact and who may change it.
State the distinction between permission and eligibility. A service representative may be authorized to request replacements, but a particular request may exceed the remaining quantity or refer to an ineligible item. A technical account may be allowed to process requests without being allowed to increase the entitlement.
NIST’s Secure Software Development Framework 1.1 recommends identifying security requirements and modeling risks during design, then maintaining the resulting decisions. It provides a development discipline, not a guarantee that every implementation preserves its business rules. NIST SP 800-218, PW.1
A hypothetical five-unit entitlement
Suppose a hypothetical customer has an approved entitlement to five replacement units. A service representative submits a request for three through the application, while an authorized integration submits another request for three against the same entitlement.
If both paths independently read a remaining balance of five before either records its allocation, each request can pass a local quantity check. Together they allocate six units, exceeding the approved entitlement by one. Both callers may have valid identities and permission to submit requests; the shared business limit still fails.
The authoritative service needs a concurrency-safe way to evaluate and record the allocation as one protected state transition. Depending on the implementation, this might use a transaction with appropriate locking or a conditional update against a versioned state. The design must be tested under concurrent execution rather than inferred from sequential demonstrations.
Under the stated all-or-nothing request policy, one three-unit request can succeed, leaving two units. The other three-unit request must receive the defined insufficient-entitlement outcome. If partial allocation is a supported business option, that requires an explicit contract and authorized handling rather than silent reinterpretation.
Now suppose the successful response is lost and the same request is retried. A stable operation identity and defined duplicate behavior should let the service return or establish the original outcome without consuming another three units. A new request with different intent must remain distinguishable from a retry.
All quantities and policies are hypothetical. The example concerns replacement-unit authorization. Any accounting, payment, customer-communication, or physical-fulfillment process requires its own authorized design and controls.
Place enforcement at the authoritative boundary
The browser can show remaining entitlement and prevent obvious mistakes, but its view may be stale. The authoritative service must enforce the rule when state changes. The same requirement applies to APIs, scheduled jobs, imports, and support tools.
Keep the entitlement source trustworthy. A caller should not be able to declare its own approved maximum or change the relationship between a request and the entitlement it consumes unless specifically authorized. Validate identifiers, units, quantities, and lifecycle state against controlled records.
OWASP ASVS 4.0.3 explicitly addresses unsynchronized shared state and resistance to time-of-check/time-of-use races in high-value business logic. This is a useful verification reference for the entitlement design, not a claim that choosing a particular database automatically satisfies it. OWASP ASVS 4.0.3, V1.11.2–V1.11.3
Decide what happens when authoritative state cannot be reached. A cached balance may support an informational display, but it should not silently authorize new consumption beyond the system’s defined safe operating mode. Availability requirements need an explicit degraded-process design rather than an accidental bypass.
Model the entire entitlement lifecycle
An allocation can be requested, reserved, fulfilled, canceled, or expired. Define which states consume entitlement and how transitions affect the balance. A canceled request may release a reservation only when the business conditions and downstream state permit it.
Do not assume a cancellation can reverse a physical action already completed elsewhere. If fulfillment has occurred, the remaining-entitlement calculation and any corrective action need the appropriate business assessment. The application should preserve the evidence rather than simply subtracting a number from a counter.
Authorized entitlement increases need their own controlled path. Identify the actor, supporting evidence, permissible adjustment, and audit record. A support role that can edit the maximum directly can bypass the protection even if ordinary requests are perfectly synchronized.
Preserve the relationship between adjustments and allocations. An operator investigating a balance should be able to explain the original grant, subsequent approved changes, active consumption, and releases. A single mutable “remaining units” field may be insufficient evidence if its history cannot be reconstructed.
Turn the risk model into concrete tests
Test the permitted request, the excess request, and the exact boundary quantity. Test concurrent submissions through different channels, repeated delivery of one operation, and reuse of an operation identifier with different input. Expected outcomes should include persistent state as well as the response returned to the caller.
Test lifecycle interactions. A cancellation arriving during fulfillment, an entitlement adjustment during allocation, or an expired request replayed later can expose assumptions absent from the simple success path. The tests should follow approved business rules rather than inventing technical defaults.
Test privileged paths and configuration changes. A background worker should not obtain permission to change the approved limit merely because it processes allocations. A support utility should not bypass the shared state transition without a separately authorized and recorded procedure.
OWASP ASVS also calls for functional security constraints, threat modeling, and documented trust boundaries. Those activities help connect the test cases to the application’s actual flows and responsibilities. OWASP ASVS 4.0.3, V1.1
Use shared security services without outsourcing the business rule
Established identity, access-control, logging, and secrets-management capabilities can reduce duplicated implementation. NIST SSDF recommends support for standardized security features where appropriate. The application still owns the meaning of the entitlement and the consistency of its state transitions. NIST SP 800-218, PW.1.3
A login service establishes identity under its contract. It does not establish that five approved units remain available. A gateway can limit traffic or authenticate an integration while the downstream application still needs to evaluate the requested business action.
Define the responsibility at each boundary. Record which component validates the caller, which evaluates scope, which owns entitlement state, and which verifies downstream completion. Missing or duplicated responsibility can create either a gap or conflicting decisions.
Protect the configuration and deployment path that can alter these rules. Changes to permission mappings, transaction behavior, service credentials, or retry settings can affect the invariant without an obvious change to the user interface. Include them in review and regression testing.
Design investigation and recovery before launch
Retain enough evidence to connect the approved entitlement, operation identity, allocation decision, state transition, and downstream reference where relevant. Keep secrets and unnecessary personal information out of general-access logs.
If an incident leaves an allocation outcome uncertain, the recovery process should establish current authoritative state before retrying or releasing entitlement. A restarted worker must not assume that a missing local acknowledgment means no allocation occurred.
Restoration requires similar care. A backup may predate allocations that remain valid in another system. Reconcile those effects before resuming new consumption. Recovering the database process alone does not prove the business limit has been restored correctly.
Assign an owner for suspicious patterns, unexplained adjustments, and inconsistent balances. A technically blocked request may be an ordinary mistake; a repeated pattern may deserve investigation. The evidence should support assessment without treating every rejected request as proof of misconduct.
Keep the security model current
Revisit the design when a new channel, integration, entitlement type, or lifecycle state is introduced. A rule that works for one-item all-or-nothing requests may not automatically support bundles, partial fulfillment, or transfers between entitlements.
Maintain the risk decisions and approved exceptions with owners and review triggers. An exception for a controlled pilot should not silently become the default for broad deployment. Automated tests should preserve the important denied cases as the application evolves.
There are tradeoffs. Strong shared-state enforcement can introduce contention or dependence on an authoritative service. More elaborate lifecycle tracking adds implementation and operating effort. Address those costs deliberately through the architecture rather than weakening the invariant without an authorized risk decision.
Start with one business limit that several application paths can affect. Define its trusted evidence, state transitions, concurrent behavior, replay semantics, and privileged adjustment route. Security is built into the application when those conditions remain true across the whole lifecycle, not merely when each individual caller passes a login check.
