Build a cybersecurity portfolio project: a personal learning portal

Define the project and its honest limits

You need the skills from a first API project, a session lab, a user-data lab and safe frontend practice. Use your own individual verified account and an authorized project. While verification is pending, a local prototype with fictional data can demonstrate the interface and state transitions.

The portal has three study items: HTTP fundamentals, session handling and safe output. Each item has a self-reported completion checkbox and a note limited to 200 characters. There is no central administrator roster. A checked item does not prove course completion, grant access or issue a certificate. These constraints keep the project small enough to explain and review thoroughly.

Draw the architecture before writing the interface

The browser loads your frontend and the documented SDK, then connects to Gammal Tech’s hosted API. You do not install the platform on the website server. The API documentation describes the global methods for login, session checks and per-user data.

Keep three boundaries visible in your drawing: the publishing account that controls the page, the authenticated session that can access the learner’s record and the hosted data service. A compromise of the frontend can still affect data or tokens available to that page. Remote storage reduces local backend responsibilities; it does not remove frontend or account security work.

The core project has no payments, AI calls or owner notifications. Optional extensions need their own scope and budget. Check current OTP and project charges before live use instead of describing the entire project as cost-free.

Define a small record contract

Use this original example as the record shape. The module keys are fixed by the application, and all content is fictional or non-sensitive study material.

{
  "schemaVersion": 1,
  "progress": {
    "http": false,
    "sessions": false,
    "safeOutput": false
  },
  "notes": {
    "http": "",
    "sessions": "",
    "safeOutput": ""
  }
}

When reading data, accept only the expected object structure, known module keys, boolean progress values and strings within the note limit. Treat a missing or malformed field as its default. Do not copy unknown properties into page markup or future save requests. Render note text with textContent or a text input’s value.

The documented save operation merges top-level keys but replaces nested objects. When saving progress, construct the complete known progress object rather than sending one nested checkbox and assuming its siblings survive. Do not use these editable fields for roles, prices, inventory, payment status or other authoritative decisions.

Implement the portal in four reviewable milestones

1. Local interface: show signed-out, loading, ready, saving and unavailable states using clearly labeled local fixtures. Keep labels visible, support keyboard use and announce status changes without exposing technical errors.
2. Session flow: load the SDK before application code. Start login only from a user click. Use the documented session check and logout methods; never put returned tokens in URLs, screenshots or logs.
3. Read and save: after sign-in, retrieve the current record, normalize it and display it. An empty object becomes the defaults. Enable saving only when the application has a valid working state, and prevent duplicate clicks while a save is pending.
4. Review and evidence: run authorized cases, document what was observed and remove fictional notes that were only needed for demonstration.

A failed read must not be silently treated as a confirmed empty record. Show an unavailable state and avoid overwriting unknown existing data with defaults. Likewise, do not announce a successful save before the save promise resolves.

Use a test matrix that can reveal mistakes

Complete the following matrix. Use two consenting authorized learners, each with their own verified account, for the separate-user case. Do not create duplicate accounts or share credentials. Start with local fixtures; label observations from a live project separately so your evidence never implies a test you did not run.

Package the evidence and practice a client explanation

Submit a short brief, the record contract, an architecture diagram, source code, the completed test matrix and a list of remaining work. Mark simulated evidence clearly. A reviewer should be able to see which service calls exist and which behavior was demonstrated locally.

Explain the project in three parts: the customer task, the backend functions you moved to a hosted service and the controls still maintained by the website owner. Do not call it a complete cybersecurity solution or an independently audited system. OWASP’s authorization guidance reinforces the distinction between authenticating a user and permitting a business action; your portal records personal study choices rather than authoritative achievements.

For a client adaptation, the client must control its own project and accounts. Your personal portfolio project is not a place to collect a client’s customer data or sales.

Score the project and choose the next skill

Missing evidence earns no points for the affected criterion. The score measures this project, not professional qualification. Next, study HTTP security, browser behavior, trusted authorization and authorized testing. An optional AI helper or owner notification can become a later project with separate privacy, abuse and cost checks.

Common questions

Can I show every learner’s progress in an administrator dashboard?

That is outside this project and is not promised by the per-user storage workflow. Assess any shared reporting requirement and its authorized data access separately.

Can the progress checkboxes issue a verified certificate?

No. Learners can edit their own progress. A verified award would require a separate trusted assessment and authorization process beyond this personal study portal.