AP® Cybersecurity · Unit 5: Securing Applications and Data · Topic 5.1
Application and Data Vulnerabilities and Attacks
Applications turn user requests into actions on data. A weakness in design, code, configuration, identity, dependencies, APIs, storage, encryption, or operational practice can let a threat expose, alter, delete, misuse, or make that data unavailable.
Application and data security foundations
An application vulnerability is a weakness in how software is designed, built, configured, integrated, deployed, or maintained. A data vulnerability is a weakness in how information is collected, validated, classified, accessed, transmitted, stored, backed up, retained, shared, or destroyed. The two are connected: applications are often the pathways through which people and systems reach data.
| Term | Meaning | Defensive example |
|---|---|---|
| Vulnerability | A weakness that could be used or triggered. | A school portal fails to verify that a requested record belongs to the signed-in student. |
| Threat | A circumstance or actor capable of causing harm. | A criminal, malicious insider, malware campaign, or accidental cloud misconfiguration could expose records. |
| Exploit | A method or code that takes advantage of a vulnerability. | A crafted request takes advantage of the missing authorization check. No payload is needed to understand the risk. |
| Attack | An attempt to compromise confidentiality, integrity, or availability. | An unauthorized party attempts to view, change, delete, or export student records. |
| Risk | The likelihood and impact of harm to an asset. | Exposure of health or identity data carries greater consequences than exposure of public event information. |
Risk model: risk ≈ likelihood × impact. Data sensitivity, user population, internet exposure, privileges, dependencies, and recovery readiness all affect the result.
Where application weaknesses come from
Insecure design occurs when security requirements, trust boundaries, abuse cases, privacy, failure behavior, or recovery are missing from the plan. Perfectly written code can still implement an unsafe design.
Coding errors include unsafe data handling, incorrect logic, race conditions, memory mistakes, error leakage, missing checks, and use of dangerous functions or interfaces.
Security misconfiguration includes default credentials, debug mode, verbose errors, open storage, unnecessary services, broad cross-origin settings, sample accounts, unsafe cloud permissions, or missing security headers.
Outdated software leaves fixes unapplied. Unsupported frameworks, database engines, plugins, or services may never receive another security update.
Libraries, dependencies, plugins, build tools, and update channels can contain known flaws or malicious changes. Teams must inventory direct and transitive components and obtain them from trusted sources.
Weak authentication and recovery make account takeover easier. Poor session management can expose or fail to revoke authenticated sessions.
Excessive permissions give users, services, applications, database accounts, or cloud roles more access than required, increasing the effect of compromise or mistakes.
Weak logging, alerting, change control, backups, secret management, or incident response can let attacks remain unnoticed and make recovery slower or incomplete.
Build-time risk
Design choices, source code, dependencies, secrets, build systems, tests, and release pipelines determine what reaches production.
Run-time risk
Configuration, identity, permissions, network boundaries, cloud services, keys, monitoring, and administrator actions determine how the application behaves.
Data-life-cycle risk
Collection, use, sharing, retention, backups, exports, logs, analytics, and disposal can expose data even when the main application is secure.
Input handling, injection, XSS, and CSRF
Applications must treat input from forms, URLs, files, cookies, headers, mobile clients, APIs, databases, and third parties as untrusted until it has been validated for the intended purpose.
Accept only data that fits the business rule
Server-side validation checks type, length, range, format, structure, size, and permitted values. Allow-listing expected input is often clearer than trying to list every dangerous possibility. Validation does not replace context-aware output encoding or parameterized commands.
Keep data separate from instructions
Use parameterized queries, safe APIs, structured commands, context-aware encoding, trusted template behavior, and least-privileged service accounts. Avoid building interpreter commands by joining untrusted text.
| Attack class | Defensive explanation | Primary safeguards |
|---|---|---|
| Injection | Untrusted data is interpreted as part of a command or query rather than remaining ordinary data. The interpreter may perform unintended actions. | Parameterized interfaces, strict validation, safe APIs, least privilege, secure error handling, tests, and monitoring. |
| SQL injection | A database query is constructed unsafely so user-controlled input can change its intended meaning. Effects may include unauthorized reading, modification, deletion, or authentication failure. | Prepared or parameterized queries, safe object-relational tools, database least privilege, input validation, code review, and authorized security testing. |
| Cross-site scripting (XSS) | Untrusted content is rendered by a website as active browser content. It may act within the victim’s session, change the page, or expose data available to client-side code. | Context-aware output encoding, safe framework templates and DOM APIs, HTML sanitization where markup is allowed, Content Security Policy as a backup layer, and secure cookies. |
| Cross-site request forgery (CSRF) | A signed-in user’s browser is tricked into sending an unwanted state-changing request to a service that trusts the existing session. | Unpredictable anti-CSRF tokens, appropriate SameSite cookies, origin checks, safe HTTP-method design, and reauthentication for sensitive actions. |
Validation, encoding, and authorization solve different problems
Validation asks whether input is acceptable. Encoding ensures data remains data in a particular output context. Authorization decides whether the authenticated identity may perform the requested action on the requested resource. Secure applications need all three.
Broken access control, IDOR, and vulnerable APIs
Broken access control occurs when an application does not consistently enforce what an authenticated or anonymous user may view or do. Hiding a button, guessing that a URL is secret, or trusting a mobile app to enforce access is not enough; the server must verify authorization for every protected request.
An insecure direct object reference (IDOR)—often discussed in APIs as broken object-level authorization—occurs when a request identifies a record, file, account, or object but the server fails to verify that the requester is permitted to access that specific object. Object identifiers are references, not proof of permission.
Why APIs need their own security attention
Exposed endpoints
APIs publish functions for browsers, mobile apps, partners, devices, and services. Old versions, debug routes, undocumented endpoints, and administrative functions expand the attack surface.
Object and property access
Every endpoint should verify who may access the requested object, which properties they may read or change, and which function their role may perform.
Resource and business limits
Set size, rate, pagination, time, cost, and concurrency limits. Protect sensitive workflows from unsafe automation and investigate unusual API use.
Authentication and sessions
Protect tokens, validate issuers and audiences, use short suitable lifetimes, revoke when needed, avoid exposing secrets in URLs or logs, and reauthenticate sensitive actions.
Third-party trust
Validate data returned by external APIs, restrict destinations and permissions, monitor dependencies, and plan for provider compromise or outage.
Inventory and retirement
Maintain owners, purpose, version, data classification, dependencies, environments, and exposure. Remove deprecated endpoints rather than leaving forgotten access paths.
Protecting sensitive data
Sensitive data can be exposed by the main database, an API response, logs, analytics, browser storage, temporary files, exports, backups, screenshots, test systems, error messages, cloud buckets, support tickets, or human sharing.
| Risk | Possible impact | Defensive approach |
|---|---|---|
| Insecure transmission | Data or credentials are intercepted or altered between clients, services, and databases. | Use authenticated encrypted protocols such as current TLS, validate certificates, protect service-to-service links, and avoid sensitive data in URLs. |
| Unprotected storage | Lost devices, stolen media, exposed databases, or copied backups reveal readable data. | Classify and minimize data; encrypt at rest; secure files, databases, object storage, exports, and backups; protect recovery paths. |
| Weak cryptography | Obsolete algorithms, incorrect modes, predictable values, or home-made designs fail to protect confidentiality or integrity. | Use approved modern libraries and protocols, secure defaults, expert review, and planned algorithm migration. |
| Poor key management | Keys are exposed in code or logs, shared too broadly, never rotated, lost, or available to the same compromised service as the data. | Use managed secret or key systems, least privilege, separation of duties, rotation, revocation, audit logs, backup, and recovery procedures. |
| Misconfigured storage | Databases, cloud buckets, file shares, snapshots, or backups become public or broadly accessible. | Deny by default, use private network paths, review permissions, continuously assess configuration, and alert on public or cross-account exposure. |
| Excessive retention | Old data increases breach impact and privacy obligations without adding value. | Collect the minimum, apply retention rules, delete safely, and verify that replicas and backups follow policy. |
Confidentiality
Prevent unauthorized disclosure with access control, encryption, minimization, masking, secure sharing, and monitoring.
Integrity
Prevent or detect unauthorized modification with authorization, validation, transactions, digital signatures or integrity checks, versioning, logs, and change control.
Availability
Reduce deletion, ransomware, corruption, resource exhaustion, and outage impact through resilient design, rate limits, protected tested backups, redundancy, and incident response.
Exfiltration
Watch for unusual exports, API volume, archive creation, outbound transfers, new sharing links, disabled logs, or access from unfamiliar identities. Correlate before concluding.
Malware, ransomware, insiders, and accidental disclosure
Malware can steal application secrets, alter transactions, scrape databases, capture sessions, change source or build artifacts, and use legitimate application access for harmful purposes.
Ransomware may encrypt databases and file shares, stop applications, delete recovery options, and steal data before disruption. Protected tested backups support recovery but do not prevent disclosure.
Supply-chain compromise can enter through a library, plugin, package registry, source account, build service, signing key, vendor update, or outsourced provider.
Malicious insiders may misuse authorized access, while contractors or former staff may retain access longer than intended. Least privilege, separation of duties, logging, and timely offboarding reduce risk.
Accidental disclosure includes emailing the wrong file, publishing a storage bucket, sharing a link too broadly, using production data in testing, committing secrets, or misapplying database permissions.
Backup exposure occurs when copies have weaker encryption, access control, monitoring, retention, or deletion than production—even though they may contain the same sensitive data.
Warning signs of compromised applications or exposed data
Application behavior
- Unexpected errors, redirects, pop-ups, content, administrator functions, or configuration changes
- Sudden performance loss, resource spikes, outages, or unusual API response sizes
- New services, dependencies, plugins, scheduled tasks, build artifacts, or deployments without approval
Identity and access
- Login spikes, repeated failures, unfamiliar sessions, privilege changes, disabled MFA, or new service accounts
- Users viewing objects outside their role or automated access to many records
- Former staff, vendors, test accounts, or tokens remaining active
Data and storage
- Records changed or deleted unexpectedly, files encrypted or renamed, exports created, or backup jobs disabled
- Public storage alerts, new sharing links, unusual database queries, or large outbound transfers
- Sensitive data appearing in logs, errors, analytics, URLs, caches, or test environments
Security visibility
- Web application firewall, database, API gateway, cloud, DLP, integrity, or endpoint alerts
- Logging stops, retention changes, audit records are cleared, or time synchronization fails
- Vulnerability scanners identify exposed services, outdated components, leaked secrets, or configuration drift
An alert is a lead, not a verdict
Authorized analysts compare alerts with baselines, change records, asset criticality, user context, other logs, and independent evidence. False positives waste time; false negatives hide harm. Detection requires both tools and human investigation.
A layered defensive program
- Design securelyDefine data classification, trust boundaries, roles, abuse cases, privacy, failure behavior, recovery targets, and security requirements before coding.
- Build safelyUse secure coding standards, parameterized queries, safe frameworks, input validation, output encoding, peer review, automated tests, secret scanning, and controlled dependencies.
- Deploy carefullyHarden configuration, patch components, protect keys, enforce least privilege and MFA, segment services, inventory APIs, and deny access by default.
- Operate and recoverCentralize logs, monitor changes and data movement, test authorization, scan dependencies, rehearse incident response, and restore from protected verified backups.
| Practice | What it reduces | Important limitation |
|---|---|---|
| Secure coding and review | Logic, input-handling, error, authorization, and unsafe-interface defects. | Reviewers and tools can miss flaws; begin with secure design and test continuously. |
| Patching and dependency management | Known vulnerabilities in frameworks, libraries, plugins, runtimes, databases, and services. | Updates can introduce compatibility risk; inventory, trusted sources, testing, verification, and rollback planning matter. |
| Authentication and access control | Account takeover, excessive privilege, IDOR, unauthorized functions, and broad data access. | Checks must be consistent on every request, object, property, and administrative action. |
| Encryption and key management | Readable interception, stolen storage, exposed backups, and undetected modification when integrity protection is used. | Encryption does not limit an authorized-but-compromised application; keys and endpoints remain critical. |
| Backups and resilient recovery | Deletion, corruption, ransomware, software failure, and operational mistakes. | Backups may contain vulnerabilities or stolen data; protect, separate, test, and select known-good recovery points. |
| Testing and monitoring | Unknown flaws, configuration drift, abuse, data movement, and delayed detection. | Testing must be authorized and scoped; alerts require tuning, context, retention, and trained investigation. |
Application-security decisions in context
Website
A comments feature treats submitted text as data, uses server-side validation, context-aware output encoding, safe templates, restrictive cookies, and CSP as an extra layer against XSS.
Mobile application
The app stores minimal data, protects tokens in platform storage, uses TLS, validates server certificates, requests only necessary permissions, and relies on server-side authorization rather than hidden buttons.
School system
Every record request checks that the signed-in student, teacher, or administrator has permission for that exact record and action. Audit logs flag bulk access and unusual exports.
Cloud service
Storage is private by default, administrator roles use MFA and least privilege, configuration changes are logged, public-access settings trigger alerts, and backups are encrypted and tested.
Database
The application uses parameterized queries and a limited database account. Administrators separate duties, encrypt connections and storage, monitor sensitive queries, patch the engine, and protect keys separately.
Shared lesson
Secure applications combine design, code, configuration, identities, dependencies, APIs, data controls, monitoring, backups, people, and incident response throughout the software life cycle.
Watch: application and data risk
As you watch, identify one root cause, one possible data impact, and two complementary defensive controls.
Interactive knowledge check
Secure the Stack
Choose the strongest defensive answer. The quiz runs in your browser and collects no personal information.
What the quiz covers
Security vocabulary, insecure design and configuration, dependencies, authentication and sessions, input handling, injection, XSS, CSRF, access control and IDOR, APIs, encryption and keys, storage, supply-chain risk, warning signs, and layered defenses.
How scoring works
There are 10 questions worth one point each. Answer every question, select Check my answers, review each explanation, and restart for another attempt.
AP® Cybersecurity study support
Trust boundary
A point where data or control crosses between components with different trust assumptions.
Attack surface
The collection of reachable interfaces, functions, identities, dependencies, and data paths.
Parameterized query
A query structure that keeps untrusted values separate from database instructions.
Endpoint
An exposed application or API address that accepts requests for a function or resource.
Data minimization
Collecting, processing, sharing, and retaining only the data needed for a defined purpose.
Transitive dependency
A component used indirectly because another dependency relies on it.
Exam reasoning pattern
Name the asset and weakness, distinguish threat from attack, explain the CIA impact, identify the trust boundary, and select preventive, detective, and recovery controls with clear limitations.
Continue studying
Explore RevisionTown computer science resources, connect encryption and key management with the cryptography guide, or structure revision with the AP® self-study guide.
Frequently asked questions
1. What is an application vulnerability?
It is a weakness in software design, code, configuration, identity, dependencies, APIs, deployment, or operations that could contribute to unauthorized actions or harm.
2. What is a data vulnerability?
It is a weakness in how data is collected, validated, accessed, transmitted, stored, backed up, retained, shared, logged, or destroyed.
3. What is SQL injection?
It is an injection risk in which untrusted input changes the intended meaning of a database query. Parameterized queries, least privilege, validation, review, and authorized testing reduce the risk.
4. How are XSS and CSRF different?
XSS causes untrusted content to run as active browser content. CSRF tricks a signed-in browser into sending an unwanted request that relies on its existing session.
5. What is IDOR?
An insecure direct object reference occurs when an application uses an object identifier but fails to verify that the requester may access that exact object.
6. Why are APIs vulnerable?
APIs expose many functions and objects to browsers, apps, devices, partners, and services. Weak inventory, authentication, authorization, validation, limits, or configuration can expose data and actions.
7. Does encryption prevent every data breach?
No. Encryption protects specific states and paths. A compromised authorized application may still access decrypted data, while exposed keys or endpoints can undermine protection.
8. What is software supply-chain risk?
It is the risk of vulnerabilities or malicious changes entering through dependencies, plugins, build tools, source repositories, registries, signing systems, vendors, or update channels.
9. Can backups be a data-exposure risk?
Yes. Backups may contain the same sensitive data as production but have weaker permissions, encryption, monitoring, retention, or deletion controls.
10. What is the best overall defense for applications and data?
Use defense in depth across secure design and coding, dependency maintenance, configuration, identity, authorization, encryption, key management, backups, testing, monitoring, and incident response.
Trusted references
AP® is a trademark registered by the College Board, which is not affiliated with and does not endorse this page. This lesson provides defensive cybersecurity education. Application, API, database, cloud, identity, and data-security testing must be explicitly authorized, scoped, monitored, and conducted under applicable policy, privacy requirements, and law.
