I9.3 Secure Input, Output, and Data Handling
Learn how fictional developers define server-side input contracts, separate data from structure, use safe APIs, protect files, handle output for exact destinations, minimize sensitive information, control storage and exports, preserve defender evidence, enforce retention, and complete safe deletion.
Lesson Progress
Secure Input, Output, and Data Handling
High School Intermediate • I9: Secure Coding Basics • Lesson 3 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
Data Can Be Safe in One Stage and Unsafe in the Next
A fictional report label may be safe in a database but unsafe if inserted through raw markup. A valid record identifier may still refer to an object the user cannot access. A document may be an approved type but stored in a public location. A useful log event may expose too much private content. Secure coding follows the data through every interpretation and ownership boundary.
Weak approach
“The fictional value came from our database and passed the browser form, so it is trusted everywhere.”
Strong approach
“Validate the exact input contract, authorize the object, keep values separate from structure, handle each output context, and control collection, storage, sharing, retention, and deletion.”
Objective 1
Explain how fictional data moves from browser, API, file, message, integration, and administrator inputs through validation, authorization, processing, storage, logging, rendering, export, retention, and deletion.
Objective 2
Distinguish client-side usability checks, server-side validation, structural allowlists, parameterization, safe APIs, output-context handling, sanitization, file controls, and authorization.
Objective 3
Design fictional input contracts that define approved fields, types, formats, ranges, sizes, relationships, states, and business rules before data reaches sensitive operations.
Objective 4
Evaluate fictional data handling for collection, classification, minimization, encryption, access, storage, logging, retention, export, backup, recovery, and safe disposal.
Objective 5
Create a professional fictional Secure Input, Output, and Data Handling Review with findings, owners, tests, evidence gaps, monitoring, rollback, and closure criteria.
Why This Matters
Secure Data Handling Protects Both Systems and People
Fictional input weaknesses can affect query behavior, object access, file processing, destinations, configuration, and business transactions. Output weaknesses can affect browsers, documents, messages, logs, and exports. Poor minimization and retention can expand the impact even when application controls work. Professional teams define exact contracts and preserve only the data required.
Data Lifecycle
Eight Stages from Collection to Disposal
1. Collection
A fictional application receives only the fields, files, identifiers, and metadata needed for an approved workflow.
Defensive controls
Purpose definition, field minimization, consent or notice where required, type and size limits, authentication, authorization, and source identification.
Evidence
Form or API schema, data inventory, privacy requirement, route review, owner approval, and positive and negative tests.
Failure mode
The application collects optional, sensitive, or unrelated data because it might be useful later.
2. Validation
A fictional server checks structure, type, format, range, length, relationship, state, and business rules before processing.
Defensive controls
Strict schemas, unknown-field rejection, server-defined choices, canonicalization rules, file policy, and object authorization.
Evidence
Schema, validation logs, safe errors, test cases, rejected requests, and no-operation database records.
Failure mode
The application trusts browser controls, hidden fields, file names, client roles, or stored values without server checks.
3. Processing
A fictional application uses approved operations while keeping data separate from query, command, path, template, or configuration structure.
Defensive controls
Parameterization, safe APIs, fixed operation mappings, least privilege, transaction boundaries, timeouts, and resource limits.
Evidence
Code review, operation map, prepared-operation record, service identity, transaction log, and resource metrics.
Failure mode
Untrusted values influence structure, destinations, file paths, query fields, or administrative behavior.
4. Storage
A fictional system stores only required data under appropriate access, encryption, integrity, backup, and ownership controls.
Defensive controls
Classification, encryption decisions, least privilege, tenant isolation, integrity checks, private storage, key management, and backup policy.
Evidence
Data model, storage configuration, key reference, access review, backup record, and recovery test.
Failure mode
Sensitive data is stored in broad tables, public files, client-managed state, logs, or long-lived temporary locations.
5. Use and access
A fictional identity accesses data only for an approved role, object, tenant, workflow, and business purpose.
Defensive controls
Authentication, object authorization, role and relationship checks, field filtering, reauthentication, approval, and audit logging.
Evidence
Access decision, account and role, object and tenant, workflow state, transaction, user report, and access review.
Failure mode
The application authorizes the page but not the exact object, field, export, or downstream action.
6. Output and sharing
A fictional application displays, renders, exports, logs, emails, or shares data safely for the exact destination and audience.
Defensive controls
Context-specific encoding, safe binding, sanitization, destination allowlists, data minimization, authorization, expiry, watermarking, and secure transfer.
Evidence
Source-to-sink map, component review, export record, audience, link expiry, browser result, and policy event.
Failure mode
Stored or internal data is treated as trusted when moved into a new browser, document, log, message, or integration context.
7. Retention and recovery
A fictional organization keeps data, logs, exports, and backups only for approved periods and can recover required information safely.
Defensive controls
Retention schedule, legal or business hold, backup encryption, access controls, restore testing, versioning, and owner review.
Evidence
Retention policy, object age, backup inventory, restore test, hold record, owner approval, and deletion queue.
Failure mode
Production data is deleted while backups keep indefinite copies, or logs expire before investigations can use them.
8. Disposal
A fictional organization removes data, exports, temporary files, indexes, links, accounts, secrets, and access paths when no longer required.
Defensive controls
Approved deletion workflow, ownership verification, dependency review, backup expiration, key retirement, audit evidence, and exception handling.
Evidence
Deletion request, object inventory, completion record, backup status, key action, access test, and owner sign-off.
Failure mode
The primary record is deleted while exports, caches, previews, search indexes, or third-party copies remain available.
Input Contracts
Eight Input Groups with Server-Side Rules
Account and identity fields
Approved input
Fictional account identifiers, role requests, recovery references, and device labels in exact documented formats.
Required checks
Type, length, normalization, existence, account state, role eligibility, tenant, recovery policy, and rate limits.
Unsafe assumption
The account name or role received from the browser is already trusted.
Evidence
Identity lookup, policy decision, validation event, account state, and negative tests.
Record and object identifiers
Approved input
Fictional opaque identifiers resolved by the server to a trusted tenant, owner, relationship, and object.
Required checks
Format, existence, tenant, ownership, assignment, object state, action, and session context.
Unsafe assumption
A valid-looking identifier proves the user may access the object.
Evidence
Object resolution, authorization decision, database result, and wrong-object tests.
Text and rich content
Approved input
Fictional plain text or narrowly defined rich text with separate processing paths.
Required checks
Length, required fields, character handling, audience, business rules, safe binding, sanitizer policy, and destination review.
Unsafe assumption
Stored, internal, or staff-created content is safe in every output context.
Evidence
Schema, source-to-sink map, component result, sanitizer output, and browser validation.
Search, sort, and filter choices
Approved input
Fictional choices mapped to a small server-defined set of fields, directions, operators, and ranges.
Required checks
Allowlisted name, type, range, page size, date window, authorization, result limit, and timeout.
Unsafe assumption
Any received field name or operator can become query structure.
Evidence
Operation map, prepared read, query plan category, result count, and unsupported-choice tests.
Dates, numbers, and quantities
Approved input
Fictional typed values within documented minimums, maximums, precision, time zone, and business relationships.
Required checks
Type, format, canonical time zone, range, precision, ordering, uniqueness, quota, and workflow state.
Unsafe assumption
A value that parses is automatically reasonable and allowed.
Evidence
Parsed value, normalized value, business-rule decision, transaction result, and boundary tests.
Files and attachments
Approved input
Fictional approved document categories within size limits, stored privately with generated names and controlled processing.
Required checks
Declared and observed type, size, count, filename handling, authorization, isolated processing, storage path, expiry, and viewer behavior.
Unsafe assumption
A familiar filename extension proves the content is safe.
Evidence
Upload decision, generated object ID, storage policy, processing result, access decision, and unsupported-file tests.
URLs and destinations
Approved input
Fictional exact owned or partner destinations required by the workflow.
Required checks
Scheme, host, path rules, allowlist, redirect handling, audience, purpose, expiry, and user-visible destination.
Unsafe assumption
Any well-formed destination is approved and harmless.
Evidence
Destination resolution, allowlist version, redirect result, owner approval, and unapproved-destination tests.
Administrative and configuration values
Approved input
Fictional server-defined feature, role, policy, environment, and configuration choices available only to approved administrators.
Required checks
Privileged role, reauthentication, dual approval where required, allowlisted value, environment, change ticket, and rollback.
Unsafe assumption
Administrative input can be free-form because administrators are trusted.
Evidence
Role and session, change record, before-and-after configuration, validation, and audit event.
Core Concept
Use the Contract–Operation–Context–Lifecycle Chain
Purpose
Why does the fictional workflow require this field, file, object, or data set?
Contract
Which fictional type, format, range, relationship, state, size, and authorization are allowed?
Operation
Which fictional safe API, fixed mapping, transaction, identity, and resource limit processes it?
Context
Where will the fictional value appear, render, navigate, log, export, notify, or integrate?
Lifecycle
How will the fictional data be stored, accessed, backed up, retained, shared, and deleted?
Evidence
Which fictional tests, logs, storage records, browser results, owner reviews, and business outcomes prove the result?
Output Safety
Eight Destinations That Need Different Handling
Visible browser text
Safe pattern
Use fictional framework text binding or a safe text-node API that keeps content as text.
Risk
Raw markup insertion can turn data into browser-interpreted structure.
Validation
Reserved and markup-like characters appear visibly without creating elements or actions.
Owner: Front-End Team
Approved rich text
Safe pattern
Use a maintained fictional sanitizer with a documented allowlist, safe destinations, and content policy.
Risk
Broad or outdated sanitizer policy can preserve unsafe elements, attributes, destinations, or embedded behavior.
Validation
Approved formatting remains while unsupported content is removed or converted to text.
Owner: Front-End and Platform Teams
HTML attribute
Safe pattern
Use framework-managed fictional properties with validation appropriate to the exact attribute.
Risk
String construction can break attribute boundaries or create unintended browser behavior.
Validation
Inert boundary values remain data and the final DOM contains the expected property only.
Owner: Front-End Team
URL and navigation
Safe pattern
Use exact fictional destination allowlists, safe URL builders, approved schemes, clear user display, and redirect limits.
Risk
Untrusted destinations can mislead users or send data to an unapproved location.
Validation
Approved destinations work while unapproved schemes, hosts, paths, and redirects are rejected.
Owner: Application Team
Structured script data
Safe pattern
Use fictional framework serialization designed for the exact data boundary and avoid building executable text.
Risk
Manual string construction can turn data into program structure.
Validation
Supplied inert values remain serialized data and never become executable instructions.
Owner: Front-End and Platform Teams
Logs and alerts
Safe pattern
Use structured fictional fields, length limits, safe rendering, redaction, and no secrets or unnecessary personal data.
Risk
Untrusted values can confuse analysts, corrupt display, expose private data, or break parsing.
Validation
Events parse correctly, line breaks remain safe, sensitive fields are absent, and viewers render values as text.
Owner: Application and Security Operations Teams
Email and notification
Safe pattern
Use fictional trusted templates, exact recipient and destination rules, safe text or approved markup handling, and data minimization.
Risk
Dynamic recipients, links, markup, or private content can create misdelivery or deceptive messages.
Validation
Approved recipients and content work while wrong-audience, unapproved-link, and unsupported-markup cases fail.
Owner: Communications Technology
Export and document
Safe pattern
Use fictional document libraries, explicit field selection, safe cell and formula handling, authorization, expiry, and protected storage.
Risk
Exports can expose excess fields, preserve dangerous interpretation, remain accessible too long, or reach the wrong audience.
Validation
Only approved fields and rows appear, inert values remain data, access expires, and unauthorized users cannot retrieve the file.
Owner: Reporting and Data Teams
File Handling
Eight Controls for Fictional Uploads and Downloads
Purpose and category
Accept only fictional file categories required by a documented business workflow.
Evidence
Requirement, route, allowed category, owner, and business use.
Negative test
Unsupported categories are rejected before storage or processing.
Size and count
Limit fictional individual size, total request size, file count, processing time, and storage quota.
Evidence
Policy, request metadata, processing metrics, quota, and rejection event.
Negative test
Oversized, excessive-count, and quota-exceeding submissions fail safely.
Name and storage key
Generate fictional server-side object identifiers and treat the original name as display metadata only.
Evidence
Generated object ID, storage path, original-name field, and retrieval mapping.
Negative test
Boundary-like file names do not control paths or overwrite unrelated objects.
Type review
Compare fictional declared type, observed file structure, approved category, and processing capability.
Evidence
Declared type, observed category, policy decision, and processing result.
Negative test
Mismatched or unsupported content is denied or isolated.
Private storage
Store fictional files outside direct public paths with object authorization and controlled retrieval.
Evidence
Storage policy, object owner, access decision, signed-link expiry, and audit event.
Negative test
Anonymous, wrong-tenant, expired-link, and unassigned access fail.
Isolated processing
Use fictional restricted services for preview, conversion, or inspection with minimal permissions and resource limits.
Evidence
Service identity, sandbox policy, timeout, result, and monitoring.
Negative test
Failed or unsupported processing cannot access unrelated files, secrets, or services.
Safe download and preview
Use fictional safe content types, disposition, isolated viewers, clear names, authorization, and expiry.
Evidence
Response headers, viewer, file ID, account, object decision, and expiry.
Negative test
Unapproved inline display, stale links, and unauthorized previews fail.
Retention and deletion
Remove fictional temporary uploads, previews, failed objects, expired links, and unnecessary copies on schedule.
Evidence
Retention rule, object age, deletion record, backup status, and owner review.
Negative test
Expired objects cannot be accessed through primary, preview, cache, or old-link paths.
Data Protection
Eight Areas Beyond Validation
Collection minimization
Secure pattern
Collect fictional fields only when they are required for the documented purpose and current workflow.
Risk
Extra sensitive data increases exposure, access complexity, retention cost, and user impact.
Evidence
Data inventory, field purpose, route schema, owner, and privacy review.
Encryption decisions
Secure pattern
Protect fictional transport and selected stored data or backups according to classification, threat model, platform capability, and key ownership.
Risk
Encryption without access control, key management, rotation, or recovery can create false confidence or outages.
Evidence
Classification, key reference, algorithm category, owner, rotation, access, and recovery test.
Access and field filtering
Secure pattern
Return only fictional fields needed by the approved identity, role, object, tenant, and workflow.
Risk
A user may be authorized for the record but not every sensitive field inside it.
Evidence
Field policy, role and relationship, response shape, negative tests, and audit event.
Logging and redaction
Secure pattern
Log fictional decisions and identifiers needed for defense while excluding secrets, full sensitive content, and unnecessary personal data.
Risk
Logs can become a second sensitive database with broad access and long retention.
Evidence
Event schema, redaction rule, sample event, retention, access review, and viewer behavior.
Export control
Secure pattern
Use fictional exact field and row selection, privileged authorization, reauthentication, approval, protected files, expiry, and audit evidence.
Risk
Exports can bypass normal page filtering and create long-lived concentrated copies.
Evidence
Export request, approvals, job, file, field list, expiry, download, and deletion.
Backup and recovery
Secure pattern
Protect fictional backups with narrow access, encryption, inventory, retention, restore testing, and deletion alignment.
Risk
Backups can preserve deleted data, old secrets, vulnerable builds, and unreviewed access.
Evidence
Backup set, encryption, owner, access review, restore result, retention, and disposal record.
Third-party sharing
Secure pattern
Share fictional minimum approved data with exact providers under documented purpose, identity, schema, security, retention, and deletion rules.
Risk
Provider scope, ownership, copies, logs, support access, or retention may exceed the application’s controls.
Evidence
Integration inventory, data map, contract, destination, schema, test, monitoring, and owner review.
Deletion and retirement
Secure pattern
Remove fictional primary records, exports, caches, previews, indexes, temporary files, links, backups on schedule, and access paths when no longer required.
Risk
Partial deletion leaves discoverable or recoverable copies outside the primary database.
Evidence
Deletion workflow, copy inventory, completion record, backup expiry, key action, access test, and sign-off.
Defensive Workflow
Review Input, Output, and Data in Six Steps
Define the data purpose
Identify fictional users, business need, fields, files, objects, sensitivity, destinations, owners, retention, and deletion expectations.
Write the input contract
Define fictional fields, types, formats, sizes, ranges, relationships, states, allowlists, authorization, and unknown-field behavior.
Choose safe processing
Use fictional parameterization, safe APIs, fixed mappings, generated identifiers, least privilege, transactions, timeouts, and resource limits.
Map every output context
Track fictional data into text, rich content, attributes, URLs, logs, messages, files, exports, integrations, caches, and backups.
Test and correlate
Run fictional positive, negative, boundary, authorization, file, output, retention, and deletion tests with source and business evidence.
Monitor and close
Review fictional failures, drift, exports, unusual access, retention, deletion, exceptions, rollback, residual risk, and owner approval.
Correlated Data Timeline
Follow a Fictional Report Request from Requirement to Retention
09:00:00
Requirement
A fictional reporting feature must allow approved department and date filters while limiting results to authorized records.
The business and authorization purpose is defined.
09:05:00
Schema
The modern endpoint allows department, start date, end date, sort choice, and page size with exact types and ranges.
A server-side input contract exists.
09:08:00
Code review
Approved sort choices map to server-defined operations and all data values use supported parameterized interfaces.
The modern processing path separates values from structure.
09:12:00
Legacy review
A fictional legacy endpoint accepts arbitrary sort text and builds operation structure dynamically.
A confirmed unsafe construction weakness exists.
09:15:00
Access review
The legacy endpoint checks authentication but not department assignment before returning summary rows.
Input safety and object or scope authorization are both incomplete.
09:18:00
Safe test
A fictional teacher requests an unsupported sort choice and an unassigned department in the supplied test environment.
The test exercises two defensive requirements without using real systems.
09:18:01
Database
The legacy path returns summary rows from the unassigned department.
A test-environment authorization impact is confirmed.
09:22:00
Containment
The legacy report route is disabled in the test release and removed from navigation.
Narrow containment prevents release of the known path.
09:30:00
Remediation
The route adopts the modern schema, server-defined sort mappings, parameterized reads, department authorization, result limits, and safe errors.
The implementation aligns with input and access requirements.
09:42:00
Positive test
An approved teacher retrieves the correct assigned department summary.
Legitimate report use remains available.
09:46:00
Negative test
Unknown fields, invalid dates, unsupported sorts, excessive page sizes, unassigned departments, and expired sessions are denied before database access.
Several input and authorization failures are controlled.
09:50:00
Output test
Fictional report labels with reserved characters remain visible text in the browser and export.
The reviewed output paths preserve data as data.
09:55:00
Logging review
Structured events record request ID, account, route, validation result, authorization result, and row category without report content or secrets.
Defensive evidence is preserved with minimization.
Day 7
Monitoring
No unassigned report results appear, validation failures remain within expected patterns, and no schema drift is detected.
Short-term operation supports the remediated control.
Day 30
Retention review
Temporary exports expire and are deleted according to the fictional seven-day rule.
Data handling continues after request processing and display.
Key Vocabulary
Input, Output, and Data Handling Terms
Untrusted input
Fictional data that comes from a browser, API client, file, message, integration, administrator, database, cache, queue, or other source and must be validated for the current use.
Input contract
A fictional server-side definition of allowed fields, types, formats, sizes, ranges, relationships, states, and required business rules.
Allowlist
A fictional rule that permits only explicitly approved values, formats, fields, operations, destinations, or file types.
Parameterization
A defensive technique that keeps fictional data values separate from the structure of a supported query or operation.
Safe API
A fictional framework or library interface designed to keep values separate from instruction structure when used correctly.
Output context
The fictional destination where data is placed, such as visible text, HTML attribute, URL, style, script data, document, log, email, notification, or export.
Encoding
A defensive transformation that represents fictional data safely for one exact output context without changing its intended meaning.
Sanitization
A defensive process that removes or rewrites unsupported parts of fictional rich content according to a documented policy.
Data minimization
A fictional practice of collecting, storing, displaying, logging, sharing, and retaining only the data required for an approved purpose.
Data classification
A fictional label that connects information sensitivity and business value to access, encryption, logging, retention, export, and disposal controls.
Retention
The fictional approved period for keeping data, backups, logs, exports, files, and evidence before review or deletion.
Safe deletion
A fictional controlled process for removing data, copies, links, keys, indexes, exports, accounts, and access paths according to policy and business needs.
Fake Dashboard
Fake Secure Data Handling Dashboard
Training dashboard for the fictional Meadowbrook reporting and student-support applications.
Reviewed data flows
58
Fictional browser, API, database, file, message, export, logging, integration, backup, and deletion flows.
Approved input contracts
46
Schemas with field, type, range, relationship, authorization, size, and unknown-field rules.
Open findings
7
Legacy construction, object scope, raw rendering, file retention, export fields, log redaction, and backup-deletion cases.
Fake SOC Alert
Legacy Report Endpoint Accepts Unsafe Structure and Scope
Source: Fake Secure Coding Review Console • Time: 09:18 AM
Fake Log Panel
Fake Input and Data Handling Timeline
09:00:00 REQUIREMENT report_filters='department,date,sort,page_size' 09:05:00 SCHEMA unknown_fields='reject' types='strict' ranges='defined' 09:08:00 MODERN_CODE sort_mapping='server_defined' values='parameterized' 09:12:00 LEGACY_CODE sort_structure='dynamic' 09:15:00 ACCESS_CHECK authentication='present' department_assignment='missing' 09:18:00 SAFE_TEST unsupported_sort='supplied' unassigned_department='supplied' 09:18:01 DATABASE unassigned_rows='returned' 09:22:00 CONTAIN legacy_route='disabled_from_release' 09:30:00 REMEDIATE schema='modern' sort='allowlist' authorization='department_verified' 09:42:00 POSITIVE_TEST assigned_department='pass' 09:46:00 NEGATIVE_TEST unknown='deny' invalid_date='deny' unsupported_sort='deny' unassigned='deny' 09:50:00 OUTPUT_TEST reserved_characters='visible_text' 09:55:00 LOGGING request_id='present' report_content='excluded' secrets='excluded' DAY7 MONITOR unassigned_results='0' schema_drift='0' DAY30 RETENTION temporary_exports='deleted'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Secure Data Handling Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Input, Output, and Data Handling
Safe Practice Lab
Complete a Fictional Secure Data Handling Review
Fictional Evidence Set
Meadowbrook Profile and Reporting Features
Review forty-four supplied fictional records covering purpose, fields, schemas, objects, authorization, operations, database state, rendering, files, logs, messages, exports, integrations, storage, backups, retention, deletion, tests, monitoring, and owners.
Required Analysis
- Define fictional purpose, classification, fields, files, users, objects, owners, destinations, retention, and deletion.
- Write server-side input contracts with types, formats, ranges, sizes, relationships, states, allowlists, and authorization.
- Review parameterization, safe APIs, fixed structural mappings, transactions, service identities, timeouts, and limits.
- Map each value to browser, document, URL, log, message, export, integration, cache, backup, and deletion contexts.
- Design positive, negative, boundary, file, object, output, retention, and deletion tests.
- Document findings, owners, remediation, monitoring, rollback, evidence gaps, residual risk, and closure criteria.
Scenario Decision Lab
A Stored Value Is Reused in a New Browser Context
A fictional report label was originally stored as plain text. A new preview component plans to insert it through a raw markup feature.
Scenario Decision Lab
A File Feature Uses Public Storage for Convenience
A fictional support-document feature accepts approved files but stores them under directly reachable public paths using original file names.
Defender Habits
Secure Input, Output, and Data Handling Checklist
Check Your Understanding
I9.3 Mini Quiz: Secure Input, Output, and Data Handling
Choose your answers first. Explanations appear only after submission.
1. What is the strongest role of fictional server-side validation?
2. Which design is strongest for a fictional sort field?
3. What does parameterization primarily protect?
4. Why must fictional stored data still be handled safely during output?
5. Which fictional file-upload pattern is strongest?
6. What does data minimization require?
7. Which closure plan is strongest after a fictional input and data-handling finding?
Portfolio Prompt
Portfolio Prompt
Create a fictional Secure Input, Output, and Data Handling Review using at least forty-four purpose, schema, object, authorization, operation, database, rendering, file, log, message, export, integration, storage, backup, retention, deletion, test, monitoring, and owner records. Include an input-contract matrix, source-to-sink map, data inventory, file-control review, findings, evidence references, positive tests, negative tests, owners, remediation, rollback, evidence gaps, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation