Security Operations · Topic 3 of 13
Application Security Techniques
Security+ application security: input validation, secure cookies, static and dynamic analysis, fuzzing, code signing, sandboxing and monitoring.
- 4 min
- Validate input on the server, and prefer allow lists.
- The Secure flag limits a cookie to HTTPS, and HttpOnly hides it from scripts.
- SAST examines code without running it, and DAST tests the running application.
What it is
Application security covers the practices that make software resist attack, from how it handles input to how it is built, tested and watched.
Most web attacks succeed because an application trusts what it receives. The core defenses are checking input, protecting sessions and testing the code before release.
How it works
Input validation
Input validation checks that data matches what is expected, such as the correct type, length and format, before the application uses it. It reduces injection attacks, buffer overflows and many other flaws.
Validation must happen on the server, because client side checks can be bypassed. An allow list approach accepts only known good values, which is stronger than trying to block known bad ones.
Secure cookies
A cookie is a small piece of data stored by the browser, often used to keep a user logged in. Two flags are important.
| Flag | Effect |
|---|---|
| Secure | The cookie is sent only over Hypertext Transfer Protocol Secure (HTTPS) |
| HttpOnly | Scripts in the page cannot read the cookie, which limits theft through cross site scripting |
Protecting session cookies is important because stealing one can let an attacker act as the user.
Static and dynamic analysis
| Technique | How it works | When |
|---|---|---|
| Static application security testing (SAST) | Examines source code or compiled code without running it | Early, during development |
| Dynamic application security testing (DAST) | Tests the running application from outside by sending inputs | Later, in a test or live environment |
| Fuzzing | Sends large amounts of random or malformed input to find crashes and flaws | During testing |
Static analysis finds issues such as unsafe functions in the code. Dynamic analysis finds runtime issues such as missing authentication on a page.
Code signing
Code signing uses a digital signature to prove who published software and that it has not been altered. The operating system or user can check the signature before installing. It helps with software updates, drivers and scripts.
A signature proves origin and integrity but does not prove that the code is free of flaws or malice.
Sandboxing
A sandbox is an isolated environment where code can run with limited access to the rest of the system. It is used to test suspicious files, to run browser content and to contain applications.
If the code is malicious, the damage stays inside the sandbox. Some malware tries to detect a sandbox and behave normally to avoid analysis.
Secure development habits
Several habits make an application harder to attack. Run the application with only the permissions it needs, so a flaw cannot be used to reach the whole server. Keep libraries and other components up to date, and watch the packages you depend on for newly reported flaws.
Do not store passwords or keys inside source code, because code is copied and shared widely. Keep error messages plain for users and detailed only in logs, so that attackers learn nothing about the internals.
Monitoring applications
Logging and monitoring record authentication events, errors, input failures and administrative actions. Unusual patterns, such as many failed validations, can show an attack in progress. Application logs should be sent to a central system so they survive if the server is compromised.
What to remember for the exam
- Validate input on the server, and prefer allow lists.
- The Secure flag limits a cookie to HTTPS, and HttpOnly hides it from scripts.
- SAST examines code without running it, and DAST tests the running application.
- Fuzzing sends unexpected input to find weaknesses.
- Code signing proves the publisher and integrity of the code.
- A sandbox contains code so that harm stays isolated.
- Central application logging helps detect attacks and supports investigations.
- Application security is part of the development process, not an add on at the end.
If a question says "without executing the program", it describes static analysis. If it says "while the application is running", it is dynamic analysis.
Common mistakes
Trusting client side validation. An attacker can send requests directly, skipping the browser.
Believing a signed program is safe. A signature identifies the publisher and shows the code is unchanged, but the code can still contain bugs or be malicious.
Confusing SAST with DAST. SAST reads the code, and DAST attacks a running instance.
Forgetting cookie flags. A session cookie without Secure and HttpOnly is easier to steal.
Assuming a sandbox is perfect. Escapes are possible, and some malware detects sandboxes.
Fuzzing and dynamic testing can crash a system. Run them against test environments, not live production.
Check yourself
Which cookie flag prevents scripts from reading the cookie?
HttpOnly.
What is the difference between static and dynamic analysis?
Static analysis checks code without running it, while dynamic analysis tests the application as it runs.
What does code signing prove?
Who published the code and that it has not been altered since it was signed.
Topic 3 of 13 in Security Operations
Test yourself on Security Operations
The full CompTIA Security+ SY0-701 question bank has 848 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.