vaayaa Inclusive Education
Technical risk assessment

Web Application Security Risk Assessment: Access, Vulnerability and Recovery Controls

A worked example of how a web application team finds, scores and controls risks to user accounts, data, availability and privacy duties, from authentication flaws to third-party code and slow incident response.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Web Application Security course

Executive summary

This assessment shows how a small web application team can find, rate and control the risks that matter most to user accounts, data, availability and privacy duties. Eight risks were chosen because they are plausible in building and running a customer-facing service. Account takeover, injection flaws and misconfigured storage are the most serious before controls, with the top score sitting at Critical for authentication and session flaws. Each risk is scored before controls and again after existing and added controls. Most risks fall to Medium or Low once added controls are in place, but the main exposures to user accounts stay at Medium because the impact remains serious. The first actions are multi-factor sign in for administrators, parameterized queries, a hardened storage baseline and a central security log. The application is a teaching example, so every score illustrates method rather than describing a real service.

Focus area
Web application security
Setting
Online service team building and running a customer-facing web application with a hosted back end and a small operations group
Method
Likelihood and impact risk register with inherent and residual scoring

Scope

This assessment covers a customer-facing web application, its browser front end, application programming interfaces, hosted servers and database, and the processes that build, deploy, log and respond to incidents. It considers confidentiality, integrity and availability of user data, and the duties that apply to personal data. Hosting provider, jurisdiction, data volumes and development method are assumptions made for teaching and are labelled as such.

Context

The application lets registered users create accounts, manage profiles, place orders and view personal records. It runs on a managed cloud platform with a relational database, third-party authentication and analytics libraries, and a continuous delivery pipeline. A small engineering team, an operations lead and a support desk share duties. Each hazard is scored before controls to show its natural level, then again after existing and added controls.

Objectives, assets and stakeholders

The objective is to keep the application available and trustworthy, protect user accounts and personal data, meet privacy and breach duties, and recover quickly when something goes wrong. The assets in scope are user accounts and credentials, the customer database, order and profile records, application source code, build pipeline, hosting configuration, logs and the public reputation of the service. Stakeholders include registered users, engineers, operations and support staff, administrators, the hosting and library suppliers, the data protection lead and regulators. Clear roles matter: every risk has one owner role, and the security lead keeps the register current and reports to the engineering leadership each month.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 2, score 8, medium: H06 Likelihood 4, impact 3, score 12, high: H04 Likelihood 4, impact 4, score 16, high: H02 Likelihood 4, impact 5, score 20, critical: H01
3 Possible Likelihood 3, impact 4, score 12, high: H03 H05 H07
2 Unlikely Likelihood 2, impact 5, score 10, high: H08
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible Likelihood 3, impact 2, score 6, medium: H07
2 Unlikely Likelihood 2, impact 2, score 4, low: H06 Likelihood 2, impact 3, score 6, medium: H02 H03 H04 H05 H08 Likelihood 2, impact 4, score 8, medium: H01
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Unauthorized access through authentication and session flaws 20 Critical 8 Medium Security lead
H02 Injection and unsafe input handling in application code 16 High 6 Medium Lead developer
H03 Misconfigured servers, storage and debug settings 12 High 6 Medium Platform engineer
H04 Phishing and credential theft targeting staff accounts 12 High 6 Medium IT manager
H05 Vulnerable third-party libraries and hosting supplier compromise 12 High 6 Medium Engineering manager
H06 Insufficient logging and slow incident response 8 Medium 4 Low Operations lead
H07 Service disruption from attack traffic or a faulty release 12 High 6 Medium Site reliability engineer
H08 Personal data exposure and breach of privacy duties 10 High 6 Medium Data protection lead
H01

Unauthorized access through authentication and session flaws

Technology and data Before 20 After 8

Weak sign in rules, guessable reset tokens or long lived sessions let an attacker take over a user or administrator account and read or change records.

Who or what is affected: Registered users, support staff and administrators

Causes

Reused passwords, weak reset design and session tokens that never expire.

Consequences

Account takeover, exposure of personal records, fraudulent orders and loss of user trust.

Existing controls

  • Passwords are stored using a salted hashing function.
  • Sessions expire after a period of inactivity.

Control gaps

Administrator accounts are not yet covered by a second factor, and reset flows are not tested against abuse.

Additional controls

  • Prevent: Require multi-factor sign in for administrators and enforce lockout after repeated failed attempts.
  • Detect: Alert on unusual sign in locations, reused session tokens and bursts of failed sign ins.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Security lead Target: Within 30 days Early warning: Spike in failed sign ins or session tokens reused from new network addresses.
H02

Injection and unsafe input handling in application code

Technology and data Before 16 After 6

User input is passed to database queries, commands or page output without validation, so attackers can alter queries, run scripts in other users' browsers or read hidden data.

Who or what is affected: Users, developers and the database owner

Causes

Hand built queries, custom templates and trust in client side checks.

Consequences

Data theft, altered records, script injection and emergency downtime.

Existing controls

  • Code review is required for changes to data access code.
  • Framework templates escape output by default.

Control gaps

Automated tests do not yet include malicious input cases for search and filter pages.

Additional controls

  • Prevent: Use parameterized queries and validate input against allowed formats on the server.
  • Respond: Disable a vulnerable feature quickly by feature flag while a fix is tested.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Lead developer Target: Within 45 days Early warning: Application errors showing database messages or unusual query patterns in logs.
H03

Misconfigured servers, storage and debug settings

Technology and data Before 12 After 6

Public storage locations, open administrative ports or debug pages left on in production expose files, internal details and control panels to anyone who finds them.

Who or what is affected: Users, platform engineers and the operations team

Causes

Manual changes during incidents, copied default settings and unreviewed debug flags.

Consequences

Exposure of files and secrets, unauthorized changes and a breach notice.

Existing controls

  • Infrastructure is defined in version controlled templates.
  • Administrative ports are closed to the public internet.

Control gaps

Scans cover the main servers but not the storage buckets created by test environments.

Additional controls

  • Prevent: Apply a hardened baseline and block public access to storage by default.
  • Detect: Run automated configuration scans weekly and report any drift from the baseline.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Platform engineer Target: Within 30 days Early warning: A configuration scan finding that exposes a storage location or debug page.
H04

Phishing and credential theft targeting staff accounts

People Before 12 After 6

Staff are tricked into entering codes or passwords on fake pages, giving attackers access to production consoles, code repositories and customer records.

Who or what is affected: Engineers, support staff and customers whose records are reachable

Causes

Urgent looking messages, fake login pages and reused passwords across services.

Consequences

Unauthorized production changes, data theft and a costly recovery.

Existing controls

  • Staff complete security awareness training when they join.
  • Email filters block known malicious links.

Control gaps

Training is not repeated, and staff do not yet report suspicious prompts quickly.

Additional controls

  • Prevent: Use phishing resistant multi-factor methods for every staff account with production access.
  • Respond: Revoke sessions and rotate shared secrets within one hour of a confirmed credential theft.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: IT manager Target: Within 30 days Early warning: Staff report a sign in prompt they did not start or a message asking for one time codes.
H05

Vulnerable third-party libraries and hosting supplier compromise

Supplier Before 12 After 6

Outdated libraries, plug ins or a compromised hosting or analytics supplier introduce flaws or malicious code that the team did not write and may not see.

Who or what is affected: Users, engineers and the hosting supplier

Causes

Old packages kept for compatibility, long supply chains and trust in outside scripts.

Consequences

Exposed data, hijacked pages, forced emergency releases and supplier disputes.

Existing controls

  • Dependencies are pinned to known versions.
  • The hosting agreement requires notice of security incidents.

Control gaps

Analytics scripts load from outside sources without integrity checks.

Additional controls

  • Prevent: Scan dependencies for known vulnerabilities before each release and block high severity findings.
  • Detect: Subscribe to advisories for key libraries and record the review outcome each month.
  • Recover: Keep a tested plan to replace a compromised library or move hosting quickly.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Engineering manager Target: Within 60 days Early warning: Dependency scan reports an unpatched high severity finding in production.
H06

Insufficient logging and slow incident response

Operational Before 8 After 4

Security events are not recorded, kept or reviewed in time, so an intrusion runs for weeks before anyone knows and responders cannot show what happened.

Who or what is affected: Operations staff, customers and auditors

Causes

Logs stored only on each server, no alert rules and no named incident commander.

Consequences

Slow containment, incomplete breach evidence and longer downtime.

Existing controls

  • Web server access logs are kept for a set period.
  • An on call rota covers the main service hours.

Control gaps

Application level events such as failed sign ins are not yet sent to the central log.

Additional controls

  • Detect: Forward authentication and administrator events to a central log with alerts on defined patterns.
  • Respond: Run a tabletop incident exercise each half year and record the lessons learned.
Likelihood 4 x impact 2 before; 2 x 2 after Owner: Operations lead Target: Within 60 days Early warning: Security events arriving in the central log more than one day after they occur.
H07

Service disruption from attack traffic or a faulty release

Operational Before 12 After 6

Floods of requests, expensive searches or a broken release make the application slow or unavailable to customers and staff who depend on it.

Who or what is affected: Customers, support staff and the sales team

Causes

Unbounded queries, no traffic caps and releases that skip some tests.

Consequences

Lost orders, customer complaints and emergency working hours.

Existing controls

  • The hosting platform provides basic traffic filtering.
  • Releases go to a staging environment before production.

Control gaps

Rollback has not been rehearsed since the last major change to the database.

Additional controls

  • Prevent: Set rate limits on login and search endpoints and cap request sizes.
  • Recover: Keep a rollback procedure and test it before each major release.
Likelihood 3 x impact 4 before; 3 x 2 after Owner: Site reliability engineer Target: Within 30 days Early warning: Error rate or response time above the agreed level for more than ten minutes.
H08

Personal data exposure and breach of privacy duties

Legal and compliance Before 10 After 6

Personal data is returned in responses, exports or logs beyond what is needed, or is kept too long, so a breach or misuse triggers notice and penalty duties.

Who or what is affected: Registered users, the data protection lead and regulators

Causes

Over broad API responses, copied data in logs and no retention limits.

Consequences

Notice duties, regulator action, compensation claims and reputational harm.

Existing controls

  • Personal fields are encrypted at rest in the database.
  • A privacy notice describes what data is collected.

Control gaps

Retention periods are not applied to backups or analytics exports.

Additional controls

  • Prevent: Collect only the fields the service needs and remove personal data from logs and analytics.
  • Detect: Scan outbound responses and exports for patterns of personal data each week.
  • Respond: Follow a written breach notification procedure that names the data protection lead.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: Data protection lead Target: Within 45 days Early warning: An export or API call returning more personal fields than the screen needs.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from Rare to Almost certain, and impact runs from Insignificant to Severe. Multiplying the two gives a score from 1 to 25, which falls into one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. The score is a guide for ordering work, not a measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing and added controls. Impact is judged on data exposed, hours of downtime, cost of recovery, legal duties triggered and harm to user trust. A risk is never rated down only because it has not yet happened. Anything still High needs senior attention and a dated plan, anything Medium needs routine controls with a named owner, and anything Low is accepted and watched. Engineers who build and operate the system should challenge the ratings, and each rating is reviewed when an indicator reaches its threshold or when a major release changes the design.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 6 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Failed sign in attempts per account and session tokens reused from new addresses.Escalate to the security lead when an account shows repeated failures, and lock the account pending review.
Configuration scan findings that expose storage or debug settings in production.Escalate to the platform engineer at once, and to the operations lead if the exposure is not closed within one day.
Dependency scan results showing unpatched high severity findings in production.Escalate to the engineering manager within one working day, with a patch or removal plan due within a week.
Security events reaching the central log more than one day after they occur.Escalate to the operations lead when delays persist for three days, and to the security lead for any gap in administrator events.
Exports or API responses returning more personal fields than the user interface needs.Escalate to the data protection lead at once, and hold the affected export until the field list is corrected.

Contingency arrangements

If a serious event occurs, such as confirmed account takeover, a data leak or a long outage, the incident commander is named and the affected service is isolated. Compromised credentials and sessions are revoked, and the lead developer disables the affected feature if needed. The operations lead restores service from the latest tested backup or rolls back the release. Logs are preserved, the data protection lead decides on notice duties in the relevant jurisdiction, and customers receive a clear and early message.

Prioritized action plan

  1. Enforce multi-factor sign in for all administrator accounts, owner security lead, within 30 days.
  2. Replace string built queries with parameterized queries in search and account pages, owner lead developer, within 45 days.
  3. Apply the hardened storage and server baseline and block public access by default, owner platform engineer, within 30 days.
  4. Forward authentication and administrator events to a central log with alert rules, owner operations lead, within 60 days.
  5. Rehearse rollback and the breach notification procedure, owner data protection lead, within 45 days.

Conclusion

Secure web applications depend on steady habits: strong sign in, validated input, a hardened configuration, reviewed dependencies, complete logs and rehearsed recovery. The highest scores sit with account takeover, injection and misconfigured storage, and each has actions that bring the residual score down. Treat the register as a living record, review it on the stated cycle, and seek qualified security and legal advice for any real system or privacy decision.

Assumptions and limitations

Assumptions

  • The application is hosted on a managed cloud platform run by an outside supplier under a standard service agreement.
  • Jurisdiction is not specified, so privacy and breach notification duties are described in general terms only.
  • Developers use a version control system with code review and an automated build pipeline.

Limitations

  • The scores are examples for learning and do not describe any real application, supplier or organization.
  • Security practice changes quickly and specialist review is needed before any real control decision is made.
  • This is educational content and does not replace a formal site-specific assessment or licensed security or legal advice.

Related frameworks to study

  • OWASP Top Ten awareness list of common web application risks
  • STRIDE threat modeling for spoofing, tampering and other threat types
  • Least privilege access principle
  • Defense in depth layering of controls

Technical Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

Web Application Security course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,186 Learners