Security Operations · Topic 5 of 14
Application and Repository Security
Security+ application security: secrets scanning in code repositories, input validation, secure cookies, static code analysis and code signing.
- 5 min
- Secrets scanning finds passwords, keys and tokens in repositories, including their history.
- A leaked secret must be rotated, not just deleted from the code.
- Validate input on the server, and prefer allow lists.
What it is
Application security covers the practices that make software resist attack, from where the code is stored to how it handles input and how it is released.
Most web attacks succeed because an application trusts what it receives, or because a secret was left where an attacker could find it. The core defenses are scanning repositories, checking input, protecting sessions, analyzing code and signing what is released.
How it works
Repositories and secrets scanning
A code repository stores source code and its full history of changes. Developers sometimes commit secrets by mistake, such as passwords, application programming interface (API) keys, access tokens or private keys.
Secrets scanning searches repositories for patterns that look like secrets and alerts or blocks the commit. It can run before a commit is accepted, on every push and across the full history.
| Step | Why |
|---|---|
| Scan before code is accepted | Stops the secret from entering the repository |
| Scan the full history | A secret removed from the latest version still exists in older commits |
| Rotate any exposed secret | Once leaked, a key must be treated as compromised |
| Store secrets in a secrets manager | Code then refers to the secret instead of containing it |
Deleting the file does not fix a leak. The key must be revoked and replaced, because anyone who cloned the repository may already have it.
Input validation
Input validation checks that data matches what is expected, such as the correct type, length, range 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 by sending requests directly. 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 signed in. Several attributes protect it.
| Attribute | 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 |
| SameSite | Limits sending the cookie with requests from other sites, which helps against cross-site request forgery |
| Expiration | Short lifetimes reduce the value of a stolen session cookie |
Protecting session cookies matters because stealing one can let an attacker act as the user without knowing the password.
Static code analysis
Static code analysis examines source code or compiled code without running it. Tools look for unsafe functions, missing input checks, hardcoded secrets and known insecure patterns. It runs early, during development, when fixes are cheapest.
| Technique | How it works |
|---|---|
| Static code analysis | Reads the code without executing it |
| Dynamic testing | Tests the running application from outside by sending inputs |
Static tools produce false positives, so a developer or reviewer must confirm each finding. They also miss problems that appear only at run time, such as a missing check on a live page.
Code signing
Code signing uses a digital signature to prove who published software and that it has not been altered since it was signed. The operating system or user checks the signature before installing or running it. It is used for applications, updates, drivers and scripts.
A signature proves origin and integrity but does not prove that the code is free of flaws or malice. If a signing key is stolen, attackers can sign malware that looks trusted, so signing keys need strong protection.
How the exam asks about this
- "A developer pushed an API key to a public repository." -> Revoke and rotate the key, then add secrets scanning.
- "Find flaws in source code without executing the program." -> Static code analysis.
- "Stop scripts in the page from reading the session cookie." -> Set the HttpOnly attribute.
What to remember for the exam
- Secrets scanning finds passwords, keys and tokens in repositories, including their history.
- A leaked secret must be rotated, not just deleted from the code.
- Validate input on the server, and prefer allow lists.
- The Secure attribute limits a cookie to HTTPS, and HttpOnly hides it from scripts.
- Static code analysis checks code without running it and is used early in development.
- Code signing proves the publisher and integrity of the code, not that it is safe.
- 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 testing.
Common mistakes
Deleting a leaked secret and moving on. The secret remains in history and in copies, so it must be revoked.
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.
Treating every static analysis finding as real. Findings need review, since false positives are common.
Forgetting cookie attributes. A session cookie without Secure and HttpOnly is easier to steal.
Never store passwords or keys inside source code. Code is copied, shared and backed up widely, and every copy holds the secret.
Check yourself
Which cookie attribute prevents scripts from reading the cookie?
HttpOnly.
Why must a secret found in a repository be rotated even after it is deleted?
It remains in the commit history and in any copies, so it must be treated as compromised.
What does code signing prove?
Who published the code and that it has not been altered since it was signed.
Topic 5 of 14 in Security Operations
Test yourself on Security Operations
The full CompTIA Security+ SY0-801 question bank has 998 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.