One concern, one answer.
For owners who received a security notification.
- Review the original observation
- Confirm applicability in scope
- Explain impact and uncertainty
- Recommend the next action
We map your attack surface, verify vulnerabilities by hand, explain the real impact in plain language — and prove each fix with a formal retest. No noise, no guesswork.
A security alert deserves a clear answer. We establish whether a reported issue is real, what it means, and what to do next.
A scoped assessment of your website and applications, with verified findings and a prioritised action plan.
Turn recommendations into changes. We resolve confirmed issues and retest the original findings within scope.
Keep visibility as your website evolves, with scheduled checks and reviewed notifications.
You work with the engineer who tests your site — no account managers in between.
Scope, test, report, retest — the same person keeps the full context.
Verification and retests are done in-house, by hand.
Define assets, authorisation and testing boundaries before any packet is sent.
Automated checks plus manual review separate noise from confirmed, exploitable issues.
Evidence, real impact and practical remediation — ranked by what matters first.
Apply agreed fixes, then verify each original finding is genuinely closed.
A useful security report works for decision-makers and developers alike. Every finding connects evidence to a practical next step — and a retest status.
A browser-side protection layer is absent. Context determines the practical impact — ranked accordingly.
A backup archive is reachable without authentication. Its contents still need controlled verification.
Potential exposure of source code, configuration or customer data, depending on the archive.
# deny access to backup archives - location / { - try_files $uri $uri/ =404; - } + location ~* \.(zip|tar|gz|sql|bak)$ { + deny all; # 403 Forbidden + return 403; + } # retest $ curl -I /backups/store.zip HTTP/1.1 403 Forbidden ✓
An agreed test with two controlled accounts shows a missing object-level access check (IDOR).
A user may reach another tenant’s objects. Affected operations determine severity.
// enforce tenant ownership - const order = await Order.findById(id); - return res.json(order); + const order = await Order.findOne({ + _id: id, tenantId: req.user.tenantId + }); + if (!order) return res.status(403).end(); + return res.json(order); // retest: account B → order of A 403 Forbidden ✓
A component version appears to match a security advisory. Applicability is confirmed against configuration.
Impact depends on the real version and exposed features. A version match alone is not proof.
// confirm, patch in staging, roll out - "framework": "4.2.1", // CVE-flagged + "framework": "4.8.3", // patched $ npm audit found 0 vulnerabilities ✓ $ smoke-test checkout flow 12 passed, 0 failed ✓
We agree what matters, which assets are in scope, and the outcome you need. You get a defined quote — no surprises.
A service agreement plus written authorisation for the named assets. Testing starts only once both are signed.
You provide what the test type needs: external (none), grey-box (test accounts), or white-box (source & staging).
We test only the agreed assets, in the agreed window, favouring non-disruptive techniques — with a stop-word if anything is affected.
An executive summary and technical findings with evidence — plus a call to walk your team through what matters first.
Where it’s in scope, we help fix the confirmed issues and retest every original finding to prove it’s closed.
Nothing is tested without your signed written authorisation for the named assets, in the agreed window.
For owners who received a security notification.
For a launch, an update or a security review.
For teams ready to implement changes.
A preliminary signal is not a confirmed breach. We explain what was observed, what remains unverified, and how to arrange a controlled follow-up. A notice from us is free of charge; Validate is for notices you received from anyone and want checked independently.
From publicly observable information only — public DNS records, the TLS certificate or HTTP response headers — we noticed an indicator of a possible configuration issue. We have not accessed, scanned or tested your systems, and this is not confirmed as an exploitable vulnerability.
If you are the owner or an authorised contact, we first verify ownership, then share a concise, factual description through a secure channel. Please do not send passwords, personal data or production data in reply.
● receiving this costs nothingAn observation is not a demand for payment — no deadline, no pressure. You are free to use your own team, or reply “STOP” and we will not write again.
The practice is designed for remote engagements. We agree working language, time zones, contracting requirements and service availability before starting.
The number of assets, application complexity, access level and testing depth. You receive a defined scope and estimate before work begins. Remediation and monitoring are scoped separately.
Choose “Finding validation” when you open a file. We agree a secure way to share details and confirm the recipient before disclosing sensitive evidence. Receiving information does not require purchasing remediation.
No. An assessment reflects a defined scope at a point in time and cannot guarantee the absence of other vulnerabilities. Retesting confirms the original findings are closed; later changes can introduce new issues.
Tell us what you’re building, protecting or worried about. Start with a short brief — we’ll propose a defined scope.