05 / 06

Cyber · AI · Digital intelligence

Secure, high-performance web

Build or strengthen a fast, accessible and maintainable web service aligned with its risk level.

Empty digital forensics bench with storage devices and precision tools Illustration · fictional scene

A quality website must inform, reassure, convert and remain available. We connect architecture, experience, performance, security, hosting and maintenance in one roadmap.

05

What the assignment should give you

  1. 01A clearer desktop and mobile experience
  2. 02A faster and more robust technical foundation
  3. 03Realistic maintenance that prevents invisible debt

How the assignment works

How the assignment works

A short, explicit process adapted to the sensitivity of the situation.

  1. 01

    Scoping

    We define the decision to support, relevant assets, constraints, authorised sources and required confidentiality.

  2. 02

    Investigation

    Collection and analysis follow the agreed scope. Facts, hypotheses and areas of uncertainty remain clearly separated.

  3. 03

    Prioritisation

    Each finding is assessed by reliability, likely impact and the effort required to act.

  4. 04

    Delivery

    You receive a readable synthesis, useful evidence and a roadmap that can be put into practice.

Possible deliverables

Possible deliverables

  • UX, performance and security audit
  • Website architecture or redesign
  • Hardening, backups and monitoring
  • Maintenance and continuous improvement plan

Common situations

Common situations

  • An ageing site that is hard to evolve
  • Weak loading speed, conversion or accessibility
  • Need for a sober, secure web foundation

How can the assignment’s result be verified?

Use these examples to agree on a verifiable deliverable. Checks and thresholds follow the agreed scope; the examples below are not client results.

Example evidence and decisions to agree during scoping
What to checkEvidence to requestDecision it supports
Essential journeyStart, steps, confirmation and error recovery; mobile, keyboard and zoom checks.Release when the task can finish, including after a recoverable error.
Experienced performanceLCP, INP and CLS at the 75th percentile, period, device type, URL/origin scope and available volume; lab measurements kept separate.Prioritise the observed bottleneck and flag conclusions limited by sparse data.
AccessibilityScope, tested pages and states, examined criteria, manual results and automated-tool limits.Fix documented barriers without inferring overall conformance from one score.
Maintenance and recoverySupported dependencies, access, update procedure, backups and an exercised restoration.Assign recurring checks and verify continuity after delivery.

Put the decision to the test

A fast journey that fails after an error

A mobile form responds quickly in a lab test. During a functional check, however, a validation error clears fields that were already completed.

Fictional teaching case. Figures explain the reasoning; they are neither client results nor thresholds required by a standard.

steps in the journey
5
recoverable error tested
1
fields retained after that error
0
Three possible decisions
Possible choiceMissing evidence or supporting reason
Release based only on the speed scoreSpeed does not demonstrate that the task can be completed.
Redesign the entire visual identityThe observed defect concerns retained input and error recovery first.
Fix it and replay the complete journeyCheck preserved fields, an understandable error and the final confirmation.
Read the decision and next check

Error recovery is the proposed priority. The check starts at the beginning, triggers the error, corrects the value and verifies confirmation. Include keyboard use and a 320 CSS pixel viewport to identify navigation and reading barriers.

The next check

Replay the priority task with keyboard, zoom and mobile; trigger an error and verify final confirmation. Compare field measurements for comparable populations and retain the limits of lab tests.

What this case does not demonstrate

Passing this scenario is neither a complete accessibility audit nor performance evidence for every visitor.

References and scope

  • Google / web.dev — Web Vitals

    Core Web Vitals cover loading, interaction and visual stability; assessment uses the 75th percentile of visits. They do not alone cover every aspect of service quality.

  • W3C — WCAG-EM Overview

    The method organises scope, exploration, representative sampling, evaluation and reporting. The table above prepares checks; it is not a WCAG conformance statement.

  • W3C — Understanding Reflow (WCAG 2.2, 1.4.10)

    The criterion addresses content reflow at a width equivalent to 320 CSS pixels, with exceptions for content requiring two dimensions.

References checked on 15 October 2026.

Before the assignment

Frame a useful decision

The review follows important website tasks and the conditions needed to operate them. It examines content, interface, accessibility, speed, security and maintainability together to prioritise fixes that improve the complete service. Verification follows the complete journey: find an answer, understand the offer, act and receive a usable confirmation. It connects keyboard accessibility, mobile rendering, real performance, form errors and exchange security. Every fix has an observable success criterion and post-release check so that technical improvement corresponds to a task people can complete.

Information to gather

  • Essential journeys and affected audiences
  • Available performance data and user feedback
  • Architecture, hosting and publishing cycle

Decisions to prepare

  • Improve the existing foundation or plan a rebuild?
  • Which components create repeated barriers?
  • How will recovery after an incident be validated?
  • Can a form, API or email actually finish and confirm the task?
  • Which permissions, variants or field metrics prevent a task from completing correctly?

Illustrative assignment

Situation
A request form works on desktop but loses information and poorly confirms submission on mobile.
Work
Test the complete journey with keyboard, zoom and slow network; compare technical errors, messages people see and measurement events.
Deliverable
A prioritised fix list, observable acceptance criteria and a regression check after release.

Example acceptance criteria to agree during scoping

  • The essential task completes on mobile, with keyboard and after an error.
  • An unavailable dependency does not leave misleading state.
  • Removed scripts do not return through downstream loading.
Related public methods

References: data, uses and limitations

Documentation reviewed on .

References: data, uses and limitations
Source and purposeVerified data or benchmarkHow to use itLimitation to retain
MITRE · Common Weakness Enumeration

Name classes of software and hardware weakness.

 A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests.

Explore the method →

 A keyword in a report alone does not establish the correct CWE classification.
W3C · WCAG 2.2

Evaluate accessibility criteria for web content.

 WCAG 2.2 is a W3C Recommendation. Success criteria have A, AA and AAA levels. Define tasks, pages and states, then combine inspection, keyboard, zoom and relevant assistive technology. Keep reproduction steps for barriers.

Explore the method →

 An automated scanner does not establish conformity of a complete journey. Evaluation must cover interactive states and actual content.
Google · Core Web Vitals

Distinguish loading, responsiveness and visual stability.

 Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes.

Explore the method →

 These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience.

Identity: factors, sessions and recovery

Integrate sign-in into the account lifecycle

Authentication must stay consistent with permissions, sessions and support. A biometric API or passkey button does not establish security of the entire system.

  • Verify expected protocol properties on the server.
  • Test expiry, logout and authenticator binding.
  • Check keyboard and non-biometric fallback.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, HTTP caching and concurrent updates

Web performance: revalidate without exposing personalised data

Transfer savings from 304 do not establish whether a response may be shared between users. Acceptance checks must cover access and variant selection.

  • Separate the browser’s private cache from the CDN’s shared cache.
  • Check ETag, Vary and Cache-Control for two distinct authorised test accounts.
  • Retain expected 304 headers and an access-refusal case; do not reuse a response based solely on its ETag.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After: waiting, budgets and retry decisions

Useful waiting preserves the user’s intention

A screen waiting indefinitely or recreating an operation after an error can hide a failure and generate duplicates.

  • Provide a deadline, understandable waiting state and recovery path retaining useful input.
  • Do not announce business failure from a network timeout alone.
  • Test repeat clicks and return after interruption with stable operation identity where the contract supports it.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

Build signatures and provenance

Connect delivery records to deployed bytes

An SBOM, VEX and provenance can accompany one release while carrying different information. Preserve their binding to the exact package and the expectations used to accept its origin.

  • Match artefact digest to attested subject; preserve the reference from receipt through promotion to deployment.
  • Check authorised identity, builder, repository and parameters rather than concluding from signature presence alone.
  • Retain behaviour and recovery checks: an authentic package can still regress.

Read the pre-deployment provenance reference →

Sources checked on · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures

Webhooks: signatures and replay

Design a traceable, recoverable webhook entry point

A web integration must state what its 2xx means: durable admission, completed processing or another explicit contract. Queue, concurrency and recovery must remain observable after failure.

  • Preserve the raw body before framework transformations.
  • Bind each local effect to an operation and uniqueness constraint.
  • Exercise queue failures and lost responses before production.

See webhook signatures, digests and the ten cases →

Sources reviewed on · Stripe · Webhooks · Stripe · Manage webhook endpoints · GitHub · Validating webhook deliveries · GitHub · Best practices for using webhooks · GitHub · Handling failed webhook deliveries

Files: quarantine and withdrawal

Retrieved content still needs checks before release

Uploading a document or fetching it by URL does not decide its availability. Originals and derivatives need to retain version, checks and access state through every read.

  • Isolate received files before processing and release.
  • Reject results targeting an older content version or control decision.
  • Check permissions and withdrawal for previews and originals alike.

View the three journeys and late task results →

Sources reviewed on · OWASP · File Upload Cheat Sheet · OWASP · Authorization Cheat Sheet · WHATWG · HTML input accept · PostgreSQL 18 · Transaction isolation

Pagination: consistency and recovery

Recovery follows the batch actually retained

A retry needs to know which objects were retained and under which view. Advancing continuation before confirming a batch can lose data; rereading requires deduplication and an external-effects policy.

  • Test a crash between batch retention and checkpointing.
  • Do not infer completion from page size alone.
  • Recheck permissions and reference validity on every recovery.

Compare computed reads and recoveries →

Sources reviewed on · Google · AIP-158 Pagination · PostgreSQL 18 · LIMIT and OFFSET · PostgreSQL 18 · Row constructor comparison · PostgreSQL 18 · Transaction isolation · OWASP · API1:2023 Broken Object Level Authorization

Explore the CISA KEV catalogue

Bring vulnerability tracking into maintenance

An added entry starts a work item, rather than automatically closing one. Connect tracking to inventory, a change window and service verification after intervention.

  • Assign decision and change owners.
  • Separate patch availability, deployed patch and successful verification.
  • Keep the source, observed result and remaining limits.

Explore the catalogue and method →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

IANA references and DNSSEC interpretation

Distinguish resolution, caching and web responses

An outage can occur before any HTTP response. Examine DNS resolution, its validation and caches separately from the web server.

  • Record the failing stage and the resolver involved.
  • A received TTL and RRSIG expiration are different constraints.
  • An error disappearing on one device does not prove recovery for all visitors.

Read the registries and try the cache model →

IETF · RFC 4033 · §3–5 · 2026-10-23

Forms: criteria, errors and contrast

Review states, not just the initial page

A form may look clear before entry and become difficult after an error. A useful review retains task context and connects each finding to a version and state.

  • Test waiting, error, correction and confirmation.
  • Separate colour calculation, keyboard navigation and status presentation.
  • Keep steps that reproduce the barrier.

Open the WCAG review grid and contrast calculator →

W3C WAI · Forms Tutorial · User Notifications · Practical guidance · consulted 2026-10-23

Extensions: permissions and access

Include the browser in exposure scope

A hardened site can still be visited from a profile with highly authorised extensions. Keep the boundary between site security, browser capabilities and managed-endpoint choices visible.

  • Inventory the test profile’s extensions with version and accountable owner.
  • Explain each required host and check optional permissions actually granted.
  • Test restriction and removal; static manifest reading cannot replace code and traffic observation.

Read the permission directory and manifest examples →

Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23

Syslog codes and collection evidence

Normalisation must preserve event meaning

In a distributed API, a PRI integer combines two codes. An opaque conversion may lose the message family or reverse severity. Test collection with identified events before inferring operational reliability.

  • Keep facility, severity and raw value in separate fields.
  • Distinguish source time, reception time and search availability.
  • Expose rejected events, truncation, loss and conversion rules.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

API errors: types, statuses and evidence

Handle an error without parsing its sentence

An API client may receive a translated title, missing member or unfamiliar extension. Preserve decisions based on the documented type and HTTP status, then connect a safe action to the context.

  • Compare received status and JSON status without silently replacing either.
  • Test absent type, string status instead of a number, and an unknown extension.
  • Separate person-facing text, business code and occurrence reference.

Explore problem types and eight fictional responses →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

CSP: directives, fallback and journeys

Deploy CSP with journey evidence

A monitored policy and an enforced policy have different effects. Server, CDN and proxy transformations may also result in several received policies.

  • Preserve raw policies, mode, delivery and page version.
  • Test sign-in, forms, payment and recovery within scope.
  • Connect reports, defects and stop criteria before deciding on enforcement.

Read CSP fallback orders and explore eight scenarios →

W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1

GraphQL: errors, lists and partial data

Deliver a GraphQL interface that explains missing data

Align Non-Null types with truly essential actions and define an understandable partial-record display.

  • Compare absent data, partial data and data: null.
  • Keep the original path even when a parent becomes null.
  • Test permissions, quotas and interface states separately.

Explore GraphQL responses and nullability →

GraphQL Specification · September 2025 · Published edition · September 2025

Core Web Vitals: thresholds and field data

Design performance that serves the journey

LCP, INP and CLS answer different questions. Tie every fix to a real element and action.

  • Compare the same device, scope and documented periods.
  • Do not turn missing data into zero.
  • Verify functions and accessibility after the fix.

Read the thresholds and try the p75 reader →

Google · About PageSpeed Insights · Living documentation · consulted 2026-10-23

Product identity: GTIN and variants

Product pages: connect group, variant and offer

The same reference must remain recoverable after a shared link, option change and cart transition.

  • Preserve zeros and raw values useful for acceptance checks.
  • Test the URL preselecting each variant.
  • Compare identity, price and availability on the page and in the cart.

Explore identifiers and check a GTIN digit →

GS1 · 2D Barcodes at Retail POS Implementation Guideline · Release 1.1.0 · ratified December 2025 · §4.3 / Table 4-2

Google Search Central · Product variant structured data · Updated 2026-09-08 · consulted 2026-10-23

A/B allocation: data and SRM

A/B tests: check allocation before deciding

An unexplained discrepancy may arise from assignment, the executed journey, logs or analysis filters. SRM supports investigation; it does not measure product improvement.

  • Check intended allocation and unit stability before comparing conversions.
  • Do not interpret absence of a signal as proof of overall validity.
  • Document the quality check, measured effect and deployment decision separately.

Explore the allocation check and its limitations →

Microsoft Research · Diagnosing Sample Ratio Mismatch · Published 2020-09-14 · consulted 2026-10-23

NIST/SEMATECH · Binomial distribution · e-Handbook §1.3.6.6.18 · consulted 2026-10-23

API deprecation and retirement

Plan retirement beyond the version number

A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.

  • Distinguish Deprecation, Sunset and policy links.
  • Check that Sunset does not precede Deprecation when both dates are provided.
  • Measure remaining consumers and validate the replacement before cutover.

Compare deprecation and retirement announcements →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23

Join cardinality, NULL and aggregates

Test joins that support decisions

An available API or pipeline can deliver an incorrect dashboard when source relationships disregard their grain. Acceptance should establish expected, repeated and missing rows before approving displayed metrics.

  • Retain an independent sum and both source versions.
  • Include an empty right source and repeated key.
  • Check missing values and removed rows separately.

Inspect pairs and aggregates in the workshop →

PostgreSQL 18 · Table expressions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Aggregate functions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Comparison functions · PostgreSQL 18 · documentation reviewed 2026-10-23

API amount precision and exact units

Separate exact conversion from payment confirmation

An interface can display the correct price while preparing an incorrect provider integer. Acceptance must reconcile the server amount with the operation contract, then check confirmed state without mistaking arithmetic for completed payment.

  • Test zero-, two- and three-decimal currencies.
  • Include a case where step cannot be inferred from decimals.
  • Retain an exact reference before localised formatting.

Check a unit in the workshop →

Adyen · Currency codes and minor units · Provider documentation · reviewed 2026-10-23

Stripe · Supported currencies and special cases · Provider documentation · reviewed 2026-10-23

FAQ

Frequently asked questions

Practical answers to help frame the need before an initial conversation.

Does the audit cover UX, performance and security together?

Yes. These dimensions are assessed together because a fast but confusing journey, or a clear but vulnerable one, does not create a durable web service.

Can you work on an existing website?

Yes. The assignment can begin with a focused audit, address priorities, prepare a redesign or establish ongoing maintenance according to the condition of the existing foundation.

What should be checked after a form is fixed?

Restart the journey: entry, a deliberate error, correction and confirmation. Check retained values, messages, focus movement and server-side outcome on mobile, with keyboard and zoom. A successful component alone establishes neither a working end-to-end journey nor accessibility of the entire site.

Design accessible forms and recoverable errors

W3C WAI — User Notification

Services

01Strategic intelligence & OSINT 02Cyber exposure review 03Applied AI & agents 04Due diligence & digital trust 06SEO, AEO & GEO visibility