Learners ages 14+ and adults ready for the named prerequisite; no employment or private records required.
Course 283 · Digital course 46
Handle Untrusted Input in a Browser App
Build a defensive local link-directory app with text-only rendering, allowed URL schemes, same-origin explanation and a validation matrix using inert fictional strings. Work from supplied original examples and check changed cases.
Review Build your first website and introductory JavaScript.
Add JavaScript Interactivity to a Web Page See everything you’ll needFree download · Original practice data · No external account required. Download the starter pack
A defensive local link-directory app with text-only rendering, allowed URL schemes, same-origin explanation and a validation matrix using inert fictional strings.
Your project
Start with the practice files. Build your project one lesson at a time.
Practice files are free without an account. Sign in to save your project record in My Proof: a description, checklist, and optional work link. Keep the original files in your own app or notebook; saving a project record does not upload them.
- Get your materialsDownload practice filesSupplied practice cases, a blank working record, complete lesson instructions, and annotated worked examples.
- Make your projectView the project checklist Work in your own notebook, document, or software. Use the supplied practice examples when you prefer.
- Keep a private recordSave a project record Sign in to save a description and checklist, then return to update them.
Know the route before you begin.
Here’s what you’ll need and what you’ll make. You can return to this guide during any lesson.
- Review Build your first website and introductory JavaScript.
- Use a current browser, Python 3 for loopback serving, and optional Node.js for supplied URL assertions. No account or package required.
- Keep sample strings inert and do not activate external links during the defensive validation test.
Finish with proof you can use.
A defensive local link-directory app with text-only rendering, allowed URL schemes, same-origin explanation and a validation matrix using inert fictional strings.
Save a project record in My ProofSee project checklist and review criteria
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Demonstrate literal rendering of markup-like label text using fixed DOM structure.
- Produce a parser-versus-policy matrix for accepted HTTPS and rejected scheme/relative cases.
- Show embedded-credential rejection and distinguish address validation from destination review.
- Create an origin tuple comparison and a correct browser-access boundary explanation.
- Retain inert validation tests, literal-render observations, and unchanged-list rejection evidence.
- Deliver the tested local directory with explicit implemented rules and unimplemented security boundaries.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Three ideas to help you along the way
The rules behind the steps.
State the contract
Name inputs, permitted states and observable outputs before editing the implementation.
Preserve the evidence
Keep the actual source, changed input and expected/observed record so someone can repeat the work.
Test the boundary
Check a rejection or changed case and distinguish local practice from real service or native-tool behavior.
What do these words mean?
Key terms worth knowing.
- untrusted input
- Data whose contents must not decide executable structure.
- scheme
- The leading URL protocol component such as https:.
- origin
- A scheme/host/port tuple.
- literal text
- Characters displayed without interpreting markup.
- validation boundary
- The exact conditions checked before an input is accepted.
6 lessons.
One useful project.
Work in order the first time. Each lesson makes something the next lesson can use.
- 1Up next
Separate untrusted text from executable structure
Demonstrate literal rendering of markup-like label text using fixed DOM structure.
- 219 min
Parse and allowlist URL schemes
Produce a parser-versus-policy matrix for accepted HTTPS and rejected scheme/relative cases.
- 319 min
Reject credentials and explain destination uncertainty
Show embedded-credential rejection and distinguish address validation from destination review.
- 416 min
Understand origins and browser boundaries
Create an origin tuple comparison and a correct browser-access boundary explanation.
- 526 min
Test inert rejection and literal rendering
Retain inert validation tests, literal-render observations, and unchanged-list rejection evidence.
- 628 min
Deliver a bounded defensive input project
Deliver the tested local directory with explicit implemented rules and unimplemented security boundaries.
Tools to help you practice.
Handle Untrusted Input in a Browser App practice files
Supplied practice cases, a blank working record, complete lesson instructions, and annotated worked examples.
Your course project worksheet
A downloadable text worksheet with each lesson’s working output, space for your answers, and the shared final-project checklist. Save your own copy.
Sources and further study.
Explore the references behind the lessons and take your learning further. Source notes explain access and reuse.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Start with the first useful move.
You’ll always know what to do, what to make, and where to go next.
Potential collaboration: Digital inclusion, STEM and workforce learning programs; no established partner is claimed.
Partner with LifeStarter