Sample deliverable
A sample security review report
This is the actual deliverable you receive from an Application Security Review, so you can read the format, the depth and the tone before you ever speak to us. Every finding is in plain language, scored by severity and fix effort, with the specific fix.
This example is fictional. “Example Company” is a fictional B2B SaaS, used purely to illustrate the format. The findings are realistic examples of the kinds of issues an application security review looks for, chosen to show the format, not any real company’s data. Your real report is confidential to you.
Want this for your application?
Application Security Review. Fixed price £1,200, report in 1 to 2 weeks.
We reply within one working day. Nothing is reviewed until the scope is agreed in writing.
- Client
- Example Company
- Sector
- B2B SaaS · team scheduling
- Report date
- 12/08/2026
- Stack
- Next.jsSupabaseStripeVercel
- Scope
- Web application, REST API, and Supabase backend, on a staging environment mirroring production. Scope agreed in writing before the review began.
Intended audience and reliance
This report is prepared solely for the client named in the engagement letter, for its internal use in improving the security of the application described. It is not a certification, attestation or guarantee that the application is secure, and it reflects only the systems, versions and review window in scope. No third party may rely on it, and Secvura accepts no responsibility to anyone other than the client.
Executive summary
We reviewed Example Company’s application and the systems behind it, by hand and with automated tooling, and found 8 issues. Most serious is a single critical flaw that lets one customer read another customer’s data by changing a number in the web address. Two high issues follow: an API that can return data across every customer at once, and password-reset links that never expire.
The good news is that the most dangerous issues are also among the quickest to fix. Three of the top four are a few hours of work each. We have sequenced the remediation so the highest-risk, lowest-effort fixes come first, and every finding below carries the exact change your developers need to make.
Findings by severity
These are the issues an external scan can’t see. The free Surface Check covers the outside; this review goes inside the application.
Detailed findings
The four most important findings from this engagement, shown in full. The real report also lists the 4 lower-severity items in the same format.
One customer can read another customer's data by changing an ID in the URL
The workspace dashboard trusts the numeric workspace id in the web address and never confirms, on the server, that the signed-in user actually belongs to that workspace. Any logged-in customer can change the number and load another company's schedules, members and billing contacts.
What we saw
GET /api/workspaces/4812/members returned a full member list while authenticated as a user belonging only to workspace 3307. No ownership check was applied server-side.
Why this matters: This is a direct customer-data breach that any user could trigger with a browser. It is the kind of issue that ends up in a disclosure notice and a lost enterprise deal.
The fix: Enforce ownership on every request: derive the caller's workspace from their session and reject any id they are not a member of. Back it with a Supabase Row Level Security policy so the database refuses cross-workspace reads even if a route is missed.
Estimated effort: 2 to 4 hours
The reporting API returns records across every workspace when a filter is left off
The analytics endpoint applies the workspace filter in the front-end, not the database query. Calling the API directly without that filter returns rows from all tenants in one response.
What we saw
POST /api/reports/export with an empty scope body returned 9,140 rows spanning 212 distinct workspace ids.
Why this matters: A single crafted request dumps the whole customer base's activity data. Unlike the dashboard, this needs no guessing of ids; it hands everything over at once.
The fix: Move tenant scoping into the query itself and default to the caller's workspace when no scope is supplied. Add Row Level Security as the backstop so an unscoped query can never cross tenants.
Estimated effort: 1 to 2 days
Password-reset links do not expire and can be reused
Reset tokens have no expiry and are not invalidated after use. A link from an old email, or one sitting in a mailbox or a proxy log, keeps working indefinitely and can be used more than once.
What we saw
A reset token issued 9 days earlier still completed a password change, and the same link worked a second time afterwards.
Why this matters: Anyone who ever sees a reset link, a forwarded email, a shared inbox, a leaked log, can take over the account at any time, long after the user has forgotten about it.
The fix: Give reset tokens a short expiry (15 to 60 minutes), make them single-use, and invalidate any outstanding tokens once one is used or a new one is requested.
Estimated effort: 3 to 5 hours
A read-only member can promote themselves to admin
The role-change endpoint checks that the caller is signed in, but not that they are already an admin. A member with the lowest permission level can call it and grant themselves administrative rights.
What we saw
PATCH /api/members/self with { role: "admin" } succeeded for a user provisioned as "viewer".
Why this matters: Any invited guest can quietly take full control of a workspace, including billing and member removal. Internal trust boundaries stop meaning anything.
The fix: Authorise the role-change endpoint on the caller's current role, not just their session, and forbid a user from elevating their own permissions.
Estimated effort: 2 to 3 hours
Remediation roadmap
A sequenced plan, highest-risk and lowest-effort first, so the team knows exactly what to do and in what order, whether we do the fixing or they do.
Do first
This weekHigh and critical risk, each a few hours. The biggest risk reduction for the least time.
- EXC-001
Change: Enforce workspace ownership server-side on every request, backed by a Supabase Row Level Security policy.
Effort: 2 to 4 hours
- EXC-003
Change: Give reset tokens a short expiry, make them single-use, and invalidate outstanding tokens.
Effort: 3 to 5 hours
- EXC-004
Change: Authorise the role-change endpoint on the caller's current role and block self-elevation.
Effort: 2 to 3 hours
- EXC-001
Then
Next sprintHigh risk but a larger change; schedule it into the next sprint with the isolation backstop.
- EXC-002
Change: Move tenant scoping into the database query and add Row Level Security as the backstop.
Effort: 1 to 2 days
- EXC-002
Backlog
No deadlineReal, but low impact. Fix as you touch the surrounding code; none is urgent.
4 low-severity items
The report and this plan are yours to act on. Optional remediation follows at £1,500 per 20-hour block, where we prepare the fixes and verify each one; your team ships them on your own release cycle. You are never committed to it.
Software Security Code of Practice
Where this engagement sits against the UK government’s 14 principles for software vendors, so the team knows which parts of its own self-assessment the work supports. This is not an audit or certification against the Code.
Supported by this engagement
The findings, fixes and records from this review are direct evidence for these principles.
- 1.4
Secure by design and by default. EXC-001 to EXC-004 are design and default gaps in access control, tenant isolation, authentication and roles; fixing them is the evidence.
- 3.3
Detecting, prioritising and managing vulnerabilities. Every finding is ranked by severity and effort, with a sequenced roadmap.
- 3.5
Timely security fixes. Where remediation is taken, each fix is prepared, verified and dated, giving a record of issues closed.
Covered where agreed in scope
The review reaches these only when the agreed scope includes them.
- 1.2
Knowing your components. A dependency check lists third-party packages with known issues and those that need updating.
- 3.2
Vulnerability disclosure. The review notes whether a reporting route, such as a security.txt file, is published.
Outside this review
These concern how the organisation runs, not the application, and stay with the client.
- 1.1, 1.3
The secure development framework and the release checking process the team follows.
- 2.1, 2.2
Security of, and change control over, the build environment.
- 3.1, 3.4
Secure distribution of software and reporting vulnerabilities to other parties.
- 4.1 to 4.3
Support commitments, end-of-support notice and incident information for customers.
The client completes and signs its own self-assessment. This report is for the client’s own use and is not written for any other party to rely on.
This is what lands in your inbox
One fixed price, a report like this in one to two weeks, and a clear plan you can act on the same day, whether your team does the fixing or we do. We reply to every enquiry within one working day.
Request a security reviewFixed £1,200 · report in 1–2 weeks · reply within one working day.