Application Security Development Flashcards

Question 1

What does the confidentiality, integrity, and availability model describe?

Accepted Answer

The confidentiality, integrity, and availability model describes three core security goals. Confidentiality means information is visible only to authorized parties. Integrity means data and systems change only in authorized, correct ways. Availability means legitimate users can reach systems and data when needed. Designers must balance these goals, since strengthening one can sometimes weaken another.

Question 2

What does the principle of least privilege require?

Accepted Answer

Least privilege requires that every user, process, and component receive only the access needed to do its job. Limiting permissions reduces the damage an attacker can cause after compromising one account or service. Unused permissions should be reviewed and removed regularly, since they quietly expand the attack surface over time.

Question 3

What is the defense in depth principle, and why does it matter?

Accepted Answer

Defense in depth means layering several independent security controls so that one failed control does not expose the whole system. In application code, that might mean validating input, encoding output, and checking authorization on the server. Each extra layer slows attackers and improves the chance of detection.

Question 4

What is the difference between a vulnerability, a threat, and a risk?

Accepted Answer

A vulnerability is a weakness in a system that could be exploited, such as an unchecked input field. A threat is an actor or event that could exploit that weakness. Risk combines the likelihood of exploitation with the impact of harm. Managing risk means reducing vulnerabilities, limiting threats, or accepting residual risk deliberately.

Question 5

Why should security be built in from the start rather than added at the end?

Accepted Answer

Security built in from the start is cheaper and more effective than security added after release. Early decisions about data flow and access control are hard to change later. Fixing a flaw during design costs far less than patching a deployed system. Teams that begin early also catch risks before attackers do.

Question 6

Why does a trust boundary matter in application design?

Accepted Answer

A trust boundary marks the point where data or control passes between components that trust each other to different degrees. Data that crosses a trust boundary should be treated as untrusted until validated. Drawing these boundaries helps teams decide where validation and authentication must happen.

Question 7

What is an attack surface, and how can developers reduce it?

Accepted Answer

An attack surface is the set of points where an attacker can try to interact with a system, such as APIs and file uploads. Developers reduce it by removing unused features, closing unnecessary endpoints, and limiting what each interface accepts. A smaller attack surface means fewer places where flaws can hide.

Question 8

What does it mean for a system to be secure by default?

Accepted Answer

Secure by default means a system starts in its safest reasonable configuration, so users must take deliberate action to weaken protections. Examples include requiring authentication for new accounts, enabling encryption on storage, and disabling sample or debug accounts. Safe defaults protect people who never read the documentation.

Question 9

What is threat modeling, and what questions does it answer?

Accepted Answer

Threat modeling is a structured way to identify what could go wrong in a system before it is built or changed. It usually asks what is being built, what can go wrong, what will be done about it, and whether the response is good enough. The result guides which controls to add first.

Question 10

What does the STRIDE acronym stand for in threat modeling?

Accepted Answer

STRIDE is a mnemonic for six threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Analysts check each data flow and component against every category. STRIDE helps teams think systematically rather than relying on memory alone.

Question 11

Why should developers consider security requirements alongside functional requirements?

Accepted Answer

Security requirements state what protections a system must provide, such as authenticating users, protecting stored personal data, and logging administrative actions. Treating them alongside functional requirements ensures they are designed, estimated, and tested like any other feature. Requirements written late tend to be patched in under pressure, which often creates weaker solutions.

Question 12

What does it mean to fail securely in application design?

Accepted Answer

Failing securely means that when an error or unexpected condition occurs, the system denies access or stops the action rather than leaving a door open. For example, if an authorization service times out, the application should refuse the request instead of granting access by default. This approach keeps failures from becoming security breaches.

Question 13

How does the principle of separation of duties reduce risk?

Accepted Answer

Separation of duties splits a critical task among several people or components so that no single actor can complete it alone. For example, the person who requests a payment should not also approve it. In software, the same idea appears when deployment credentials are separate from code review rights.

Question 14

Why should threat models be revisited as a system changes?

Accepted Answer

Threat models describe a system at one moment, so they become outdated when new features, integrations, or data types are added. Revisiting them during design reviews, major releases, and architectural changes keeps the analysis accurate. Each new trust boundary or external service may introduce threats that did not exist before.

Question 15

What is the difference between authentication and authorization in design?

Accepted Answer

Authentication verifies who a user or system is, while authorization decides what that verified identity is allowed to do. A system can know exactly who is logging in and still deny access to a particular record. Designers should model both separately, because a flaw in one does not automatically fix the other.

Question 16

How should teams document security decisions that involve trade-offs?

Accepted Answer

Teams should record the risk, the options considered, the chosen option, and who accepted the residual risk. Written decisions prevent the same debate from repeating and give future reviewers the context they need. This record helps teams revisit the decision when conditions change.

Question 17

What is input validation, and why should it happen on the server?

Accepted Answer

Input validation checks that data received from users or other systems matches the expected type, length, format, and range before the application uses it. Validation on the server is essential because client side checks can be bypassed by anyone who sends requests directly. Browser checks improve user experience but do not provide security.

Question 18

What is allowlist validation, and how does it differ from denylist validation?

Accepted Answer

Allowlist validation accepts only input that matches a known set of safe values or patterns, rejecting everything else. Denylist validation tries to block specific bad inputs, such as known attack strings. Denylists are fragile because attackers can find new encodings or variations that the list does not cover.

Question 19

What is output encoding, and why does it help prevent injection attacks?

Accepted Answer

Output encoding converts special characters into a safe form for the context where data will be displayed, such as HTML, a URL, or a JavaScript value. Encoding tells the interpreter to treat the data as text rather than as code. Encoding must match the destination, since HTML rules differ from JavaScript rules.

Question 20

Why are parameterized queries preferred over escaping user input in SQL statements?

Accepted Answer

Parameterized queries send the SQL command and user data separately, so the database never interprets user input as part of the command. This removes the entire class of SQL injection for those values rather than relying on the developer to escape every character correctly. Parameterization should be the default approach.

Question 21

What is cross-site scripting, and what is the main defense against it?

Accepted Answer

Cross-site scripting, or XSS, occurs when an attacker gets a page to run malicious script in another user's browser, usually by injecting content that the application displays without proper handling. The main defense is context aware output encoding of untrusted data, which keeps it displayed as text.

Question 22

Why should developers avoid building HTML or shell commands by joining strings with user data?

Accepted Answer

Joining strings with user data mixes data and code, so special characters in the input can change the meaning of the resulting command or markup. This is the root cause of many injection flaws, including SQL, command, and cross-site scripting attacks. Safer options include parameterized APIs and templating engines with automatic escaping.

Question 23

What is a canonicalization problem, and why does it matter for validation?

Accepted Answer

Canonicalization is the process of converting data to its standard, simplest form, such as decoding percent encoded characters or resolving path segments. A canonicalization problem occurs when validation happens before this conversion, so an encoded value like a dot dot path sequence slips past a filter and is decoded later. Validation should occur after canonicalization.

Question 24

How should an application handle file uploads safely?

Accepted Answer

Safe upload handling checks the file size, validates the file type against an allowlist, and does not trust the filename or the extension alone. Uploaded files should be stored outside the web root or in a separate storage service, with randomly generated names. Scanning may help but is not a substitute for these controls.

Question 25

Why is password length usually more valuable than frequent forced password changes?

Accepted Answer

Length makes passwords harder to guess or crack, while frequent forced changes often lead people to choose predictable variations. Good policies encourage long passphrases, screen new passwords against lists of commonly breached values, and allow paste into password fields. They also support password managers and rate limit failed login attempts.

Question 26

What is multi-factor authentication, and why is it stronger than a password alone?

Accepted Answer

Multi-factor authentication requires two or more different kinds of evidence, such as something you know, something you have, or something you are. Because an attacker must obtain more than one factor, stealing a password alone is not enough. Factors should be independent, so that one compromise does not expose the others.

Question 27

What is the difference between a session token and a user's password?

Accepted Answer

A password proves identity at login, while a session token proves that a previously authenticated user is still making requests. The token is issued by the server and sent with each request, often in a cookie. Stolen tokens let attackers act as the user without knowing the password.

Question 28

Why should session identifiers be regenerated after a successful login?

Accepted Answer

Regenerating the session identifier after login prevents session fixation, where an attacker plants a known identifier in a victim's browser before authentication. If the identifier stayed the same, the attacker would gain access once the victim logs in. Issuing a new random identifier at login breaks that link.

Question 29

What is role-based access control, and what problem can it create?

Accepted Answer

Role-based access control grants permissions to roles, such as editor or administrator, and assigns users to those roles. This simplifies management because permissions change in one place rather than for each person. However, roles tend to accumulate permissions over time, a problem known as role creep.

Question 30

What is the difference between broken authentication and broken access control?

Accepted Answer

Broken authentication means the system fails to correctly confirm who a user is, for example through weak login handling or predictable session tokens. Broken access control means the system correctly knows the user but fails to enforce what that user may do. Both are serious, and they often appear together in the same application.

Question 31

Why must authorization checks be enforced on the server for every request?

Accepted Answer

The server is the only component an attacker cannot modify, so it must make the final access decision. Client side hiding of buttons or menus is only a usability feature, because requests can be replayed or crafted directly. Permissions can change during a session, so checks must run on every request.

Question 32

How should a secure design handle password reset flows?

Accepted Answer

Password reset flows are a common attack path, so they should be as strong as the login they replace. Reset links should be random, single use, and expire quickly. The application should avoid revealing whether an email address has an account, and it should notify the user when a reset occurs.

Question 33

Why is it risky to store secrets such as API keys in source code?

Accepted Answer

Secrets in source code are copied into version control history, shared repositories, build logs, and developer laptops, so they are hard to fully contain. Secrets belong in a dedicated secret store or runtime configuration instead. Any exposed secret should be rotated, since deleting the line does not erase it from history.

Question 34

What does a static application security testing tool analyze?

Accepted Answer

A static application security testing tool analyzes source code, bytecode, or binaries without running the program, looking for patterns that suggest vulnerabilities. It can find issues early and at scale, such as hardcoded credentials or unsafe function calls. Its limitations include false positives and an inability to see runtime behavior or configuration problems.

Question 35

How does dynamic application security testing differ from static analysis?

Accepted Answer

Dynamic application security testing examines a running application by sending requests and observing its responses, much as an attacker would. Unlike static analysis, it does not need source code and can reveal problems that appear only at runtime. However, it covers only the paths it reaches, so it can miss flaws in untested features.

Question 36

Why do dependencies need regular review in application security?

Accepted Answer

Applications rely heavily on third party libraries, and a vulnerability in one library can expose every product that includes it. Teams should maintain an inventory of components and their versions, so they can tell quickly whether a newly disclosed flaw affects them. Updates should be tested and applied promptly.

Question 37

What is fuzz testing, and what kinds of flaws does it tend to find?

Accepted Answer

Fuzz testing feeds a program large numbers of unexpected, malformed, or random inputs and watches for crashes, hangs, or memory errors. It is especially effective at finding parsing bugs, buffer overflows, and input handling failures that ordinary tests miss. Fuzzing can run continuously and generates inputs no human tester would think to write.

Question 38

What is the purpose of code review from a security perspective?

Accepted Answer

Security-focused code review checks changes for flaws such as missing authorization, unvalidated input, weak cryptography, and leaked secrets before they merge. Reviewers look for the trust boundaries a change crosses and confirm that the right controls sit on each path. Checklists help consistency across reviewers.

Question 39

What is a security regression test, and when should one be written?

Accepted Answer

A security regression test is an automated test that checks a previously fixed vulnerability stays fixed. Once a flaw is found and patched, the team writes a test that would have failed with the vulnerable code. Running these tests in the build pipeline prevents the same weakness from returning after later changes.

Question 40

How should teams respond when a security vulnerability is reported in production?

Accepted Answer

Teams should first confirm the report and assess its severity and reach, then contain the exposure, such as by disabling the affected feature or restricting access. A fix should follow with a tested patch, a review of whether the flaw was exploited, and notification of affected parties as required.

Application Security Development Flashcards

1Core security principles

2Secure design and threat modeling

3Input validation and output encoding

4Authentication, sessions, and access control

5Secure coding and testing practices

Learning Resources