Professional Digital Projects — Batch 13

Android Kotlin · Flutter Firebase · E-commerce · Ads · AI Agents · Authorized Security Testing

6 practical projects · 72 guided checkpoints · Theory → Action → Result → Verification

Course index / విషయ సూచిక

01. Android Kotlin — Compose & Lifecycle — 12 steps

02. Flutter + Firebase — Secure Profile App — 12 steps

03. Full-Stack E-commerce — Secure Order Flow — 12 steps

04. Google Ads + Meta Ads — Measurement & Optimization — 12 steps

05. AI Agents — Safe Tool-Based Automation — 12 steps

06. Cybersecurity — Authorized Web App Testing — 12 steps

01. Android Kotlin — Compose & Lifecycle

Objective: Complete a scoped practical workflow and verify each milestone before moving to production.

Requirements: Android Studio, Kotlin, emulator or Android device

Levels: Starting → Intermediate → Advanced → Expert; these checkpoints are guided labs, not a complete production certification.

Step 01 — Create a Compose project

Theory / Why: Compose replaces XML layout with declarative UI; the app ID identifies the installed application

Practical action: Select Empty Activity with Kotlin and Jetpack Compose; use a unique application ID.

Expected output: Project sync completes and MainActivity.kt exists.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 02 — Check Gradle and SDK

Theory / Why: compileSdk controls compilation; minSdk controls supported device versions

Practical action: Run Gradle Sync and inspect compileSdk, minSdk and dependencies.

Expected output: No unresolved Gradle dependencies.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 03 — Model the screen state

Theory / Why: Immutable models make UI updates predictable

Practical action: Define data class Task(val id: Long, val title: String, val done: Boolean).

Expected output: Task can represent title and completion state.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 04 — Build a Compose screen

Theory / Why: Composable functions describe what UI should render

Practical action: Create @Composable fun TaskScreen() and call it inside setContent.

Expected output: TaskScreen appears in emulator.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 05 — Use rememberSaveable

Theory / Why: Saveable state survives common configuration recreation

Practical action: Store a text field value with rememberSaveable { mutableStateOf("") }.

Expected output: Text survives device rotation.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 06 — Add a validated form

Theory / Why: Validation prevents empty records and confusing UI

Practical action: Use OutlinedTextField and Button; reject blank trimmed input.

Expected output: Blank task is not added.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 07 — Render a list

Theory / Why: Stable keys help Compose track list rows efficiently

Practical action: Use LazyColumn with items(tasks, key={it.id}).

Expected output: New tasks appear without duplicate rows.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 08 — Implement completion

Theory / Why: Immutable updates avoid hidden mutation

Practical action: On click, map list items and copy(done = !done).

Expected output: Checkbox toggles correct row.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 09 — Separate ViewModel

Theory / Why: ViewModels preserve state across configuration changes and separate responsibilities

Practical action: Move screen state and event handlers to a ViewModel.

Expected output: UI reads state from ViewModel.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 10 — Persist with Room

Theory / Why: Room supplies a structured SQLite abstraction; DB work must not block UI

Practical action: Define @Entity, @Dao and RoomDatabase, then use suspend DAO methods.

Expected output: Tasks remain after app restart.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 11 — Handle loading and errors

Theory / Why: Real storage calls can fail; UI should explain failures

Practical action: Represent Loading, Content and Error states in UI.

Expected output: Visible error state appears on simulated failure.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 12 — Test and package

Theory / Why: Release artifacts require signing and real-device validation

Practical action: Run emulator test, rotate, background app; generate signed AAB for release.

Expected output: Debug APK works locally; signed AAB generated only after setup.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Starter example / reference

@Composable
fun TaskEntry(onAdd: (String) -> Unit) {
    var title by rememberSaveable { mutableStateOf("") }
    Column {
        OutlinedTextField(value = title, onValueChange = { title = it }, label = { Text("Task") })
        Button(onClick = { if (title.isNotBlank()) { onAdd(title.trim()); title = "" } }) { Text("Add") }
    }
}

Starter material: adapt and test in your own environment; external services and production credentials are not supplied.

Independent practice

Repeat this lab with a different test dataset, document your changes, capture the expected output and one intentionally failed test. Explain how you corrected the failure.

Knowledge check

What does the most important security or reliability check in this lab prevent?
Which step proves the result actually works?
What additional test is needed before a production release?

02. Flutter + Firebase — Secure Profile App

Objective: Complete a scoped practical workflow and verify each milestone before moving to production.

Requirements: Flutter SDK, Firebase project, FlutterFire CLI, test device

Levels: Starting → Intermediate → Advanced → Expert; these checkpoints are guided labs, not a complete production certification.

Step 01 — Create Flutter project

Theory / Why: A reproducible project is the foundation for integration

Practical action: Run flutter create profile_app and open the project.

Expected output: flutter analyze runs.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 02 — Register Firebase app

Theory / Why: Generated options connect the right app to the right Firebase project

Practical action: Run flutterfire configure and select Android project and package.

Expected output: firebase_options.dart generated.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 03 — Initialize Firebase

Theory / Why: Firebase must initialize before service calls

Practical action: Call WidgetsFlutterBinding.ensureInitialized and Firebase.initializeApp.

Expected output: App launches without initialization error.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 04 — Enable authentication

Theory / Why: Disabled providers reject sign-in regardless of app code

Practical action: Enable Email/Password provider in Firebase Authentication.

Expected output: Provider appears enabled.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 05 — Build signup form

Theory / Why: Client validation improves UX but is not security enforcement

Practical action: Validate email format and password before createUserWithEmailAndPassword.

Expected output: Valid test user registers.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 06 — Build sign-in form

Theory / Why: Authentication verifies identity; do not expose detailed account existence

Practical action: Call signInWithEmailAndPassword; show generic failure messages.

Expected output: Signed-in screen opens.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 07 — Observe auth state

Theory / Why: Streams keep UI synchronized with session changes

Practical action: Use authStateChanges stream to switch login/profile views.

Expected output: Logout returns to login.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 08 — Design profile document

Theory / Why: UID ties profile data to authenticated identity

Practical action: Use users/{uid} with displayName and createdAt.

Expected output: User document has correct owner UID.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 09 — Write security rules

Theory / Why: Client-side checks alone cannot protect Firestore

Practical action: Restrict read/write to request.auth.uid == userId.

Expected output: Unauthenticated reads denied.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 10 — Read and update profile

Theory / Why: Keep writes scoped to authenticated identity

Practical action: Fetch and update only signed-in user document.

Expected output: Profile updates visible after reload.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 11 — Test denied access

Theory / Why: Negative tests verify authorization boundaries

Practical action: Use Firestore Rules Playground or emulator with a second UID.

Expected output: Cross-user access fails.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 12 — Prepare release

Theory / Why: Production security requires more than login working

Practical action: Review privacy notice, API key restrictions, signing and test matrix.

Expected output: Release checklist completed.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Starter example / reference

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Starter material: adapt and test in your own environment; external services and production credentials are not supplied.

Independent practice

Repeat this lab with a different test dataset, document your changes, capture the expected output and one intentionally failed test. Explain how you corrected the failure.

Knowledge check

What does the most important security or reliability check in this lab prevent?
Which step proves the result actually works?
What additional test is needed before a production release?

03. Full-Stack E-commerce — Secure Order Flow

Objective: Complete a scoped practical workflow and verify each milestone before moving to production.

Requirements: Node.js, npm, SQLite/PostgreSQL, browser, payment provider sandbox

Levels: Starting → Intermediate → Advanced → Expert; these checkpoints are guided labs, not a complete production certification.

Step 01 — Define order states

Theory / Why: State transitions must be explicit to avoid double fulfillment

Practical action: Document cart, pending, paid, fulfilled, cancelled and refunded.

Expected output: Order state chart created.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 02 — Model products

Theory / Why: Integer minor units avoid floating-point price rounding

Practical action: Create products table with id, title, priceMinor, stock.

Expected output: Products have stable IDs and prices.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 03 — Model orders

Theory / Why: Historical orders should not change when product prices change

Practical action: Create orders and order_items tables with snapshots of unit price.

Expected output: Order lines retain purchase price.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 04 — Build product API

Theory / Why: Public catalog endpoints still need rate and query limits

Practical action: Implement GET /api/products with input limits.

Expected output: JSON list returns valid products.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 05 — Build cart UI

Theory / Why: Client values can be tampered with

Practical action: Track product IDs and quantities, not trusted prices.

Expected output: Cart updates quantities.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 06 — Recalculate on server

Theory / Why: Never trust price totals sent by a browser

Practical action: Look up prices and stock server-side when checkout begins.

Expected output: Tampered client total ignored.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 07 — Reserve inventory

Theory / Why: Atomic updates prevent overselling under concurrency

Practical action: Use database transaction to decrement stock conditionally.

Expected output: Oversell request rejected.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 08 — Create payment intent

Theory / Why: Payment credentials belong on server; test mode prevents real charges

Practical action: Use provider sandbox to create intent/order for server-calculated amount.

Expected output: Sandbox checkout ID returned.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 09 — Verify webhook

Theory / Why: Browser redirects cannot prove payment

Practical action: Validate provider signature and event ID before updating order.

Expected output: Forged webhook rejected.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 10 — Make webhook idempotent

Theory / Why: Providers retry events; duplicate delivery must be safe

Practical action: Store processed event IDs and ignore repeats.

Expected output: Repeated webhook does not duplicate fulfillment.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 11 — Handle refund/failure

Theory / Why: Failure paths are core business behavior

Practical action: Define stock restoration and refund workflow with audit log.

Expected output: Cancelled order no longer pending.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 12 — Run security tests

Theory / Why: Real deployments need tests beyond happy path

Practical action: Test invalid quantity, concurrency, XSS and authorization.

Expected output: Test report records passes and failures.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Starter example / reference

// Server-side checkout principle (illustrative)
const lines = await db.getProducts(cart.map(x => x.productId));
const amountMinor = cart.reduce((sum, item) => {
  const p = lines.find(x => x.id === item.productId);
  if (!p || !Number.isInteger(item.quantity) || item.quantity < 1) throw Error('Invalid cart');
  return sum + p.priceMinor * item.quantity;
}, 0);
// Use a transaction for inventory; use payment provider SDK server-side.

Starter material: adapt and test in your own environment; external services and production credentials are not supplied.

Independent practice

Repeat this lab with a different test dataset, document your changes, capture the expected output and one intentionally failed test. Explain how you corrected the failure.

Knowledge check

What does the most important security or reliability check in this lab prevent?
Which step proves the result actually works?
What additional test is needed before a production release?

04. Google Ads + Meta Ads — Measurement & Optimization

Objective: Complete a scoped practical workflow and verify each milestone before moving to production.

Requirements: Demo website, GA4, GTM, consent configuration, advertising test accounts

Levels: Starting → Intermediate → Advanced → Expert; these checkpoints are guided labs, not a complete production certification.

Step 01 — Define business objective

Theory / Why: Clicks are not the same as business results

Practical action: Choose lead, sale or signup as primary conversion.

Expected output: One measurable primary goal documented.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 02 — Map funnel

Theory / Why: Funnel stages reveal where drop-offs occur

Practical action: List impression → visit → engaged → lead → qualified lead.

Expected output: Measurement diagram created.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 03 — Create event taxonomy

Theory / Why: Consistent naming prevents fragmented reporting

Practical action: Specify lead_submit, purchase, form_error with parameters.

Expected output: Event specification table complete.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 04 — Configure GA4

Theory / Why: Centralized tags reduce duplicated tracking code

Practical action: Create web stream and configure via Tag Manager.

Expected output: Realtime test event visible.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 05 — Respect consent

Theory / Why: Privacy and platform policy apply to measurement

Practical action: Configure consent mode where applicable and avoid unauthorized personal data collection.

Expected output: Tags honor consent choices.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 06 — Verify conversions

Theory / Why: A tag firing is not proof that a conversion was counted

Practical action: Use GA4 DebugView and browser tag debugger.

Expected output: One test conversion recorded.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 07 — Create UTM convention

Theory / Why: UTMs support campaign attribution

Practical action: Use source, medium, campaign, content with consistent casing.

Expected output: Campaign URL parsed correctly.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 08 — Build Google Ads campaign

Theory / Why: Targeting and exclusions prevent waste

Practical action: Select objective, geography, negative keywords and budget cap.

Expected output: Draft campaign review completed.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 09 — Build Meta Ads campaign

Theory / Why: Platform signals and creatives affect delivery

Practical action: Define audience, placement, creative variants and pixel/CAPI plan.

Expected output: Draft campaign ready for review.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 10 — Compare creatives

Theory / Why: Small samples lead to false conclusions

Practical action: Use equal measurement windows and enough data before judging.

Expected output: Creative comparison sheet populated.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 11 — Calculate unit economics

Theory / Why: Cheap leads may be low quality

Practical action: Compute CPL, qualified CPL, CAC and return using actual costs.

Expected output: Report includes qualified lead cost.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 12 — Optimize and document

Theory / Why: Controlled changes support learning and accountability

Practical action: Pause weak variants only after validation; log changes and rationale.

Expected output: Weekly optimization log produced.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Starter example / reference

Campaign,Spend,Leads,QualifiedLeads
Search A,2000,20,8
Meta B,1800,30,6

Qualified CPL = Spend / QualifiedLeads
Search A = 250; Meta B = 300

Starter material: adapt and test in your own environment; external services and production credentials are not supplied.

Independent practice

Repeat this lab with a different test dataset, document your changes, capture the expected output and one intentionally failed test. Explain how you corrected the failure.

Knowledge check

What does the most important security or reliability check in this lab prevent?
Which step proves the result actually works?
What additional test is needed before a production release?

05. AI Agents — Safe Tool-Based Automation

Objective: Complete a scoped practical workflow and verify each milestone before moving to production.

Requirements: Python, test data, approved LLM provider or local model, sandbox

Levels: Starting → Intermediate → Advanced → Expert; these checkpoints are guided labs, not a complete production certification.

Step 01 — Choose narrow workflow

Theory / Why: Narrow scope makes evaluation and safety manageable

Practical action: Select FAQ triage or document classification with measurable output.

Expected output: Input/output contract written.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 02 — Create data policy

Theory / Why: Agents can leak data through tools or context

Practical action: Remove secrets and personal data from prompts and logs.

Expected output: Redaction checklist complete.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 03 — Define tool permissions

Theory / Why: Least privilege limits accidental damage

Practical action: Allow read-only tools first; block shell and external actions by default.

Expected output: Tool allowlist documented.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 04 — Specify structured output

Theory / Why: Schemas improve reliability but still require validation

Practical action: Require category, confidence and explanation as JSON schema.

Expected output: Invalid output rejected.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 05 — Prepare evaluation set

Theory / Why: Examples reveal failure modes before deployment

Practical action: Create 20 representative and adversarial test examples.

Expected output: Evaluation dataset saved.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 06 — Implement tool adapter

Theory / Why: Tool interfaces must be deterministic and observable

Practical action: Wrap each tool with argument validation, timeout and error handling.

Expected output: Malformed args return safe errors.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 07 — Add retrieval

Theory / Why: Grounding reduces unsupported responses

Practical action: Search approved reference documents and cite snippets.

Expected output: Answer cites retrieved source.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 08 — Defend against prompt injection

Theory / Why: Retrieved text may contain malicious instructions

Practical action: Treat documents and web text as untrusted data.

Expected output: Injected instructions ignored.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 09 — Require approval

Theory / Why: External actions can have irreversible consequences

Practical action: Place human review before sending emails, publishing or spending.

Expected output: Approval gate blocks unapproved action.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 10 — Add audit logs

Theory / Why: Audits support debugging and accountability

Practical action: Record request ID, tool, result, reviewer and outcome without secrets.

Expected output: Action trace can be reviewed.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 11 — Measure quality

Theory / Why: Agent quality must be measured, not assumed

Practical action: Track precision, abstention, cost and latency on test set.

Expected output: Evaluation report generated.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 12 — Run safe pilot

Theory / Why: Staging reduces risk during rollout

Practical action: Test in staging with no production credentials.

Expected output: Pilot checklist completed.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Starter example / reference

def approve_action(request, reviewer_approved: bool):
    if not reviewer_approved:
        return {"status": "pending_review"}
    return {"status": "approved_for_separate_execution"}
# Approval does not itself execute any external action.

Starter material: adapt and test in your own environment; external services and production credentials are not supplied.

Independent practice

Repeat this lab with a different test dataset, document your changes, capture the expected output and one intentionally failed test. Explain how you corrected the failure.

Knowledge check

What does the most important security or reliability check in this lab prevent?
Which step proves the result actually works?
What additional test is needed before a production release?

06. Cybersecurity — Authorized Web App Testing

Objective: Complete a scoped practical workflow and verify each milestone before moving to production.

Requirements: Local intentionally vulnerable test app, browser developer tools, OWASP guidance

Levels: Starting → Intermediate → Advanced → Expert; these checkpoints are guided labs, not a complete production certification.

Step 01 — Confirm authorization

Theory / Why: Testing without authorization can harm others

Practical action: Write scope, target, dates and explicit permission.

Expected output: Signed scope document exists.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 02 — Build isolated lab

Theory / Why: Isolation avoids exposure of real systems

Practical action: Use a local test app and nonproduction accounts.

Expected output: Lab responds only locally.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 03 — Create asset inventory

Theory / Why: You cannot assess controls you have not mapped

Practical action: List routes, auth roles, APIs and sensitive data types.

Expected output: Inventory table complete.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 04 — Inspect HTTPS and headers

Theory / Why: Transport and browser policies reduce common risks

Practical action: Review TLS, CSP, HSTS and cookie flags.

Expected output: Header checklist complete.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 05 — Review input validation

Theory / Why: Server validation is required even with client validation

Practical action: Test harmless invalid inputs in local forms.

Expected output: Invalid inputs rejected safely.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 06 — Check output encoding

Theory / Why: Contextual encoding mitigates XSS

Practical action: Verify user content renders as text not HTML.

Expected output: Test string shown literally.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 07 — Test authorization

Theory / Why: Authentication alone does not enforce ownership

Practical action: Use two test accounts to access own and other records.

Expected output: Cross-user request denied.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 08 — Review CSRF defenses

Theory / Why: Browser cookies may be sent automatically

Practical action: Check anti-CSRF token or same-site cookie strategy for state changes.

Expected output: Cross-site request blocked.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 09 — Review rate limiting

Theory / Why: Rate limits reduce abuse without requiring attack traffic

Practical action: Send low-volume controlled requests to local login endpoint.

Expected output: Rate limit response logged.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 10 — Scan dependencies

Theory / Why: Known vulnerable libraries need remediation

Practical action: Run package audit against test app and inspect advisories.

Expected output: Dependency report produced.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 11 — Review secrets handling

Theory / Why: Secrets should be server-side and rotated if leaked

Practical action: Check source and logs for accidental test secret exposure.

Expected output: No secrets in frontend bundle.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Step 12 — Write remediation report

Theory / Why: A useful audit ends with verified remediation

Practical action: Rank findings by impact and reproduction, then retest fixes.

Expected output: Before/after evidence recorded.

Verify: Demonstrate the result and record a screenshot or test log. If it fails, recheck setup, permissions, and exact error message before continuing.

Starter example / reference

// Express: ownership guard (illustrative)
app.get('/api/profile/:id', requireAuth, async (req, res) => {
  if (req.user.id !== req.params.id) return res.sendStatus(403);
  const profile = await loadProfile(req.user.id);
  return res.json(profile);
});

Starter material: adapt and test in your own environment; external services and production credentials are not supplied.

Independent practice

Repeat this lab with a different test dataset, document your changes, capture the expected output and one intentionally failed test. Explain how you corrected the failure.

Knowledge check

What does the most important security or reliability check in this lab prevent?
Which step proves the result actually works?
What additional test is needed before a production release?