Application Security — Glossary

The practice of integrating security principles into software development from the start rather than adding them after deployment. Secure coding addresses the inherent tension between development speed and security quality — features can be built quickly, but rushed code tends to omit input validation, use insecure functions, and skip security testing. Security+ context: secure coding is a proactive control; the alternatives (patching deployed vulnerabilities, incident response) are reactive and far more expensive.

The process of verifying that every piece of data entering an application matches what the application expects — correct type, format, length, and content. Input validation is the primary defense against injection attacks (SQL injection, command injection, XSS) and buffer overflows, which all exploit the application's failure to distinguish between expected data and attacker-crafted input. Must be applied to every input source: web forms, API parameters, URL query strings, HTTP headers, file uploads, and any other channel through which external data enters the application.

The process of converting user input into a standardized, canonical format before validation and processing. Examples: stripping leading/trailing whitespace, converting alphabetic characters to a consistent case, standardizing date formats, decoding URL-encoded or Unicode-encoded characters to their base representation. Normalization is important because attackers can sometimes bypass input validation by encoding malicious input in alternate forms (such as %3C for < in URL encoding). Normalizing first ensures the validator sees the actual intended content, not an encoded variant.

An automated security testing technique that feeds large volumes of unexpected, malformed, or random input to an application to discover vulnerabilities. A fuzzer does not know what valid input looks like — it deliberately provides invalid, boundary, or malformed values: oversized strings, special characters, null bytes, negative numbers, malformed file formats. If the application crashes, hangs, throws an unhandled exception, or behaves unexpectedly, a vulnerability has been found. Fuzzers find the edge cases that human testers miss. Attackers use fuzzing offensively; developers should use it defensively during QA to find and fix vulnerabilities before release.

A cookie with the Secure attribute set. The browser will only transmit a Secure cookie over an HTTPS (encrypted) connection — it will not send the cookie over HTTP. This prevents session hijacking via network interception: if a user accesses a site over HTTP, an attacker on the same network cannot capture the session cookie because the browser refuses to transmit it over the unencrypted connection. The Secure attribute does not encrypt the cookie's contents — it only controls when the browser transmits the cookie. Complementary attribute: HttpOnly, which prevents JavaScript from reading the cookie (protecting against XSS-based session theft).

Cookies are data files, not executable code — they cannot run malware. However, they contain information (session tokens, user identifiers) that an attacker can exploit. Cookies are not designed for secure storage: they can be read by JavaScript on the page (unless HttpOnly is set), transmitted to the server with every request, and accessed by browser extensions. Application developers must never store sensitive information in cookies — no passwords, financial data, or PII. Session tokens are the legitimate payload. The underlying storage and transmission model of cookies assumes the data is not highly sensitive.

A testing technique that analyzes application source code, bytecode, or compiled binary for security vulnerabilities without executing the application. SAST tools scan for known-vulnerable code patterns: calls to buffer-unsafe functions (gets, strcpy), string concatenation in SQL queries, hardcoded credentials, deprecated cryptographic functions. Finding vulnerabilities in code before execution means they can be fixed before deployment — when the cost of remediation is lowest. SAST integrates into CI/CD pipelines for automated scanning on every code commit.

SAST cannot find every vulnerability type. It identifies patterns in code but cannot evaluate whether the logic of the code is secure. Cryptographic weaknesses (using AES with a weak key size, improper IV handling), authentication design flaws, and business logic vulnerabilities are typically invisible to static analysis. False positives — flagged items that turn out to be safe code — require human review of every SAST finding. Developers cannot treat SAST output as a definitive vulnerability list; each finding must be evaluated in context. SAST also cannot detect vulnerabilities that emerge from the interaction of components or from runtime configuration.

The use of asymmetric encryption and digital certificates to verify that software has not been modified since it was published and that it genuinely originates from the claimed developer. Process: a Certificate Authority signs the developer's public key (vouching for identity); the developer signs the application code with their private key; the user's OS validates the signature by checking the certificate chain and comparing hash values. A valid signature proves integrity (code unchanged) and authenticity (code from this developer). An invalid or missing signature triggers an OS warning before installation. For internal enterprise applications, organizations can operate their own CA for internal code signing.

An isolation mechanism that restricts an application to only the resources it specifically needs, preventing it from accessing unrelated files, processes, or system components. Sandboxing limits the blast radius of a compromised application: even if an attacker exploits the application, they can only reach what is within the sandbox boundary. Sandboxing appears in development environments (dev sandbox isolated from production), virtual machines (VM isolation), mobile OS (each app in its own container), browser environments (iframes, JavaScript restrictions), and Windows UAC (applications run with standard user privileges by default).

Continuous real-time visibility into application activity, security events, and usage patterns. Includes four capabilities: (1) real-time monitoring of user activity and access patterns; (2) blocked attack logging — recording SQL injection attempts, unauthorized access attempts, and exploitation probes that were successfully blocked; (3) audit logs — timestamped records of authentication events, administrative actions, file accesses, and configuration changes for forensic and compliance purposes; (4) anomaly detection — identifying behavior that deviates from established baselines (spikes in failed logins, unusual data volume, off-hours access). Often integrates with SIEM, IDS, and IPS platforms.

The capability to identify application activity that deviates significantly from established behavioral baselines. Examples: sudden spike in failed authentication attempts (brute-force or credential stuffing), unusual volume of data exported by a single account (insider threat or compromised credentials), access to administrative functions by accounts that have never used them, access patterns outside normal business hours for the affected user. Unlike signature-based detection (which identifies known attack patterns), anomaly detection can identify novel attacks and insider threats that don't match any known signature — but generates more false positives requiring analyst investigation.