4.1f — Application Security (12)

Input validation

Checking that data entered into an application matches expected format or type before it's processed, preventing unexpected data from being interpreted or executed.

Fuzzing

Automated process feeding random or unexpected data into application inputs to see how the app responds, surfacing input validation gaps.

Cookie

Small data file stored in the browser, used for tracking, personalization, or session maintenance. Not executable, not malware, but can leak sensitive info if misused.

Secure cookie

Cookie flagged to only transmit over HTTPS or an encrypted connection.

SAST (Static Application Security Testing)

Analyzing source code without running it, to find vulnerabilities like buffer overflows and injection flaws before deployment.

SAST limitations

Can't catch every vulnerability class, such as flawed cryptography implementation; output can include false positives requiring developer review.

DAST (Dynamic Application Security Testing)

Testing a running application from the outside by simulating real attacks, catching issues that only appear when the app is actually executing.

SAST vs DAST

SAST analyzes code statically without running it. DAST tests the live, running application, essentially automated penetration testing.

Code signing

Developer digitally signs application code so users can verify it hasn't been altered since release and that it genuinely came from that developer. Uses asymmetric encryption and a CA-signed developer key.

Sandboxing (application/runtime)

Restricting a running application to only the data or resources it needs, isolating it from the rest of the system.

Sandboxing (development)

Separate environment where developers build and test code isolated from the production network.

Application monitoring/logging

Built-in monitoring within an app to detect attack attempts, such as SQL injection, and unusual behavior like abnormal file transfers or access spikes.