Application Security

Application input is any value the software receives from a boundary it does not fully control. HTTP headers, request bodies, environment variables, message queues, database fields, imported spreadsheets, image metadata, and administrator configuration all deserve consideration. A user interface may constrain a form field to positive integers, but the backend cannot assume that every request passed through that interface. The server needs its own contract about syntax, type, size, range, encoding, and semantic meaning. A robust design rejects malformed or unexpected input at the earliest appropriate boundary, represents valid values using types suited to their meaning, and applies domain rules after parsing.

Parsing and validation answer related but different questions. A parser maps bytes to a structured representation; validation decides whether the representation is allowed by the domain. Consider a library's academic-year field. The string 2026 can be parsed as an integer, but whether that year is allowed depends on the institution's policy and current enrollment rules. A date such as 2026-02-30 is not a valid calendar date even though each numeric component falls within a broad range. It is equally unsafe to treat a syntactically valid file path as authorization to read that path. The design should express 'which documents may this requester retrieve?' independently from the ability to parse a document identifier.

Canonicalization is the process of converting equivalent representations to a defined form before applying relevant comparisons. Unicode text can have different byte sequences that appear visually similar, and URLs can contain escapes and separators whose interpretation depends on parsing order. Defensive handling uses well-maintained parsers that agree with the downstream consumer. The strongest general practice is to avoid translating a user's string into a powerful command language when a typed API is available. Database queries should use parameterized bindings rather than string concatenation; system operations should use safe library functions with explicit arguments; template rendering should apply context-aware encoding to values displayed in HTML, attributes, URLs, and scripts. An encoder appropriate for one output context is not automatically appropriate for every context.

Output encoding protects interpretation when untrusted text is placed into another language. If a student's essay title contains characters that happen to be meaningful in HTML, those characters should be displayed as data, not executed as markup. In a server-rendered interface, escaping is applied at the output context. In a modern frontend, safe text-node APIs and trustworthy templating defaults reduce accidental executable interpretation. Disabling all escaping to allow a single rich-text widget creates a broad hazard. If the product truly needs user-authored markup, sanitize against a carefully defined allowed subset with a maintained sanitizer, keep script execution separate, and test nesting and encoded forms. Blacklisting a few suspicious tokens is a weak foundation because language grammars have many equivalent expressions.

Uploads require additional safeguards. Do not trust the filename extension as proof of format or harmlessness. Enforce size and type constraints, process content with bounded resources, store uploads outside executable application paths, randomize storage identifiers, and restrict access by ownership. Virus scanning and file inspection are useful layers but not guarantees. Image and document libraries can have parsing vulnerabilities; keep them updated and isolate resource-intensive conversion processes. A successfully parsed upload may still contain private information that should not be published. Retention and deletion rules are therefore part of input-system design, not merely compliance afterthoughts.

Defensive example. Suppose a research-archive API accepts a paper identifier, page number, and output mode. The identifier is resolved to a database record by a parameterized query. The page number is parsed as an integer, checked against the document's actual page count, and capped to prevent huge resource consumption. The output mode is selected from a small enumeration rather than copied into a shell command. The system then checks whether the requester is allowed to access the selected paper. The response uses the proper content type and a safe filename construction; audit logs record the document identifier and outcome without capturing the user's entire document. Each separate control addresses a separate failure mode.

Authentication identifies the actor according to available evidence; authorization determines which action that actor may perform on a particular resource in the current context. Security failures occur when these questions are conflated. A user who is validly logged in is not thereby entitled to view all student records, edit every research grant, or delete another person's uploaded file. Object-level authorization should be evaluated server-side for each request and enforced on the code path that accesses the resource. A hidden button and a filtered dropdown improve usability but cannot serve as the final security boundary because clients can send requests independently of the interface.

Role-based access control groups permissions into roles such as student, lecturer, department administrator, and auditor. This is useful when responsibilities are stable, but large organizations often suffer from role explosion if every exception becomes a new role. Attribute-based access control can express more detailed predicates involving subject, action, resource, and context: an examiner may enter marks only for modules assigned to that examiner during an open marking window. Relationship-based models can represent ownership and project membership. These alternatives can coexist. The design criterion is not choosing the most fashionable acronym, but making policy understandable, testable, and resistant to accidental privilege expansion.

A policy decision should include denial as an ordinary result. If a user is removed from a research group, previously valid permissions must cease according to a defined revocation policy. Caches complicate this: a cached authorization decision or data response may outlive membership changes. Systems should specify maximum staleness, cache invalidation behavior, and whether especially sensitive operations need fresh policy checks. Successful authentication does not override expired membership. Emergency access ('break glass') may be necessary in healthcare or critical operations; it should have narrow triggers, short duration, strong logging, and retrospective review rather than a shared permanent superuser account.

Consider the difference between an administrative capability and ordinary use. An application service may need to write its own table of uploaded reports but should not own the database role used to create arbitrary users and disable audit trails. Permission minimization is a reduction in the consequences of bugs. Service identities, workload identities, and short-lived credentials can help avoid one giant shared account spanning an entire environment. However, even good identity design cannot compensate for an application that performs authorization checks only on selected endpoints while bypassing them on background jobs or export functions.

Testing requires negative cases, not just happy paths. A test suite should create two legitimate users in separate projects and verify that each cannot access the other's resources. It should include ownership changes, role revocation, disabled accounts, deleted objects, expired links, concurrent updates, bulk exports, and background workers. The test should assert not only that unauthorized data is absent from the displayed screen, but that the backend refuses the operation and does not mutate persistent state. One controlled negative test often reveals a more consequential defect than dozens of screenshots proving that a normal administrator can use the application.

Policy illustration. A professor can read submissions from an assigned course, while students can read only their own submissions. Administrators may modify course membership but cannot necessarily read confidential research notes. Express the policy as a predicate permit(subject, action, resource, context) and write a set of positive and negative test vectors. If a resource changes ownership during an operation, specify whether the permission is checked once in a transaction or rechecked before a side effect. Such race conditions are not solved by merely selecting RBAC or ABAC; they require transactional and concurrency reasoning.

A session links a series of requests to an authenticated user or client within a bounded lifetime. A session identifier is a bearer secret unless additional binding is used: possession of the token can confer authority. Strong unpredictable token generation matters, but lifecycle management matters just as much. The server should create a fresh session on authentication, set appropriate expiry and idle-timeout policies, invalidate sessions on explicit logout where the architecture supports it, and rotate or revoke authority when sensitive account state changes. Every deployment should define what a stolen session could access and what an operator can do in response.

Cookies are one common method for browser sessions. Secure limits transmission to secure contexts, HttpOnly reduces access from browser scripts, and SameSite influences cross-site transmission. Each flag addresses a different exposure and no combination replaces server-side authorization or defense against cross-site request forgery in sensitive state-changing operations. Requests from the browser should use explicit anti-forgery protections appropriate to their architecture. Origins, referers, cross-origin rules, and token designs need to be understood together. A restrictive cross-origin policy does not itself prove that every state-changing operation checks an authenticated user's authority.

Token expiration has subtle tradeoffs. Short sessions reduce the time an exposed token remains useful but can harm accessibility when a student is writing a long exam answer. Sliding expiration may extend active sessions, while absolute maximum lifetime prevents indefinite continuation. Refresh tokens or renewable sessions need special protection and revocation semantics. A product should avoid forcing repeated authentication on every keystroke while still requiring stronger confirmation for sensitive operations such as changing recovery methods or exporting all records. The correct settings arise from a threat model, human factors, and service requirements rather than a universal magic number of minutes.

Session fixation is a class of lifecycle failure where an identifier accepted before authentication remains authoritative afterward. Regenerating identifiers on privilege elevation is a straightforward defensive principle. Session confusion can also occur between tenants or between a student's normal account and an administrator's elevated role if caches, cookies, or request contexts are not isolated. Cross-device logout and account recovery policies need tests: a user who reports compromise should understand whether old sessions terminate immediately, after a bounded delay, or only on individual devices. A security property that is not stated cannot be reliably tested.

Concurrency makes session management less mechanical than setting flags. Suppose an administrator revokes a user's role at time t while an export starts at nearly the same time. Should the export complete? Many systems need a transactional check with policy versioning or a clear 'authorization at start' rule for low-risk operations. A long-running bulk export may warrant periodic rechecks or cancellation upon revocation. Other operations, such as placing an equipment reservation, need idempotency keys so retries do not duplicate side effects. These examples show that session tokens and domain transactions are parts of the same authorization story.

Practical review. Map every session state: anonymous, signed in, temporarily elevated, locked, disabled, logged out, and expired. For each transition, specify how the browser, API, identity provider, and background workers learn of the change. Test invalid, old, duplicated, and cross-context requests in a sandbox. Collect evidence that the expected state changes occur without leaking account details to unauthorized callers.

Contemporary applications depend on operating-system packages, web frameworks, compiled libraries, CI runners, container images, language registries, cloud services, and build scripts. Each dependency inherits some degree of trust and may change independently from the product's own code. The risk is not limited to a known vulnerability identifier in a public advisory. Maintainer account compromise, unexpected release behavior, insecure build configuration, stolen signing credentials, and obsolete but unsupported dependencies can all matter. Sound supply-chain governance combines inventory, controlled change, reproducible evidence where practical, and tested recovery paths.

A software bill of materials can help identify which component versions appear in a release. It is a starting point rather than a certificate of safety. The existence of a listed package does not establish reachability of a vulnerable function; conversely, an incomplete inventory can make exposure invisible. Prioritization should consider known exploitation evidence, external exposure, permissions, available fixes, and the business impact of the component. Blindly updating every dependency can introduce functional regressions, while freezing every version indefinitely accumulates technical debt. The safer process is to identify critical exposure, test in a controlled pipeline, and deploy with rollback support.

Provenance answers where an artifact came from and how it was produced. Hashes show whether two byte sequences are identical but not whether the author or source is trustworthy. Signatures can bind a release to a signing identity if key management and verification are sound, yet a valid signature on malicious code remains possible when a release pipeline is compromised. Build isolation, restricted credentials, reviewed dependency changes, minimum CI privileges, and evidence retention help reduce these possibilities. Security and reliability overlap here: a corrupted build can be both a supply-chain incident and a severe service outage.

Dependency governance should name the owner of each major library and set a supported update policy. A vulnerable component in an internet-facing authentication service deserves different urgency from an unreachable development-only library, even when both have similar severity labels. A remediation plan needs an accountable decision maker, a measured deployment window, and a way to verify that the risky version is no longer shipped. Exception records should contain a reason, temporary mitigations, expiration, and re-evaluation criteria. An exception with no expiry tends to become a hidden commitment to indefinite exposure.

Case study. A small student portal uses a third-party PDF converter. Its maintainers announce end of support, but the converter remains part of automated transcript exports. The security team inventories where it runs, what permissions it has, what files it reads, whether it receives untrusted documents, and whether it can contact the network. They compare supported alternatives using test files and fixed expected outputs, isolate the old converter while migration proceeds, and document a shutdown date. A recommendation to 'run a vulnerability scanner' alone would miss major architectural questions: privileges, file confidentiality, availability, and vendor-support continuity.