Vulnerability research on web applications
The other half of the same craft. The defenses I spend the rest of my time getting past — for data — are the ones I get into here, for flaws.
Attack surface is mapped at scale with the same extraction engineering that powers the scrapers; the interesting part is then read by hand, because authorisation and business-logic flaws have no signature for a scanner to match. Everything is tested inside a published scope and disclosed through the program that owns it.
How the work runs
Five phases, in order. The first two are automated and wide, the last three are manual and narrow — that ratio is the entire method.
Map the surface
Certificate Transparency, DNS, archived paths and sitemaps first, because scope statements describe intent and CT logs describe reality. The output is an inventory of hosts and endpoints, not a vulnerability list.
Reduce it
Fingerprint what is running, score the headers, follow the redirect chains, screenshot everything. Most of an attack surface is uninteresting; the work is deciding quickly which few percent is not.
Read the application
Manual, through an intercepting proxy. Object identifiers, authorisation boundaries, multi-step flows, anything that fetches a URL on the server’s behalf. Scanners find what they have signatures for — logic flaws have no signature.
Prove it minimally
A finding is a reproducible request sequence with a stated impact. Access is demonstrated to the shallowest depth that establishes severity, and then testing stops. Nothing destructive, nothing bulk.
Disclose it
Through the program’s own channel, with the exact reproduction steps, the affected component and an honest severity argument. Nothing is published before a fix ships and the program agrees.
Phases 01 and 02 are literally the scraper catalog pointed at a different question. A crawler that can enumerate a marketplace reliably can enumerate an attack surface reliably; only the output schema changes.
What the research looks for
Weighted towards the classes where a human still beats a scanner by a wide margin.
Broken access control
IDOR, missing object-level checks, tenant boundaries that hold in the UI and not in the API. The most common real finding in modern applications, and the one automated scanners are worst at, because the request is well-formed — it is simply asking for someone else’s object.
Authentication and session handling
OAuth and SSO flows, redirect_uri handling, state and PKCE, token scope and lifetime, password reset and email-change sequences, session fixation and invalidation on logout. Multi-step flows fail at the joins between the steps.
Server-side request forgery
URL parameters, webhooks, importers, PDF and image renderers, and anything that fetches a link on the server’s behalf. Reachability of internal services and cloud metadata is what makes this severe rather than interesting.
Injection and template evaluation
SQL and NoSQL, command execution, server-side template injection, XXE, and deserialisation. Confirmed with a minimal, non-destructive proof — a controlled read or a timing signal, never a payload that damages data.
Business logic and race conditions
Coupons, credit, quota, ownership transfer, invitation and approval workflows. State that is checked and then acted upon in two steps can be attacked between the two. No scanner has the domain model needed to see it.
Exposed secrets and artefacts
Keys in JavaScript bundles and source maps, tokens in CI logs and public repositories, backups and configuration files left inside a webroot. Every candidate is validated for reach and privilege before it is reported — an inert key is noise, not a finding.
Infrastructure and takeover
Dangling DNS records pointing at deprovisioned services, unclaimed buckets and pages, expired domains still trusted by an application, and cache or CDN rules that serve one user’s response to another.
Client-side
DOM XSS and sinks reachable through postMessage, prototype pollution feeding a gadget chain, CORS policies that reflect any origin, and CSP that is present but bypassable. Reported with the exact sink, not a screenshot of an alert box.
The recon toolkit is public
12 of the published scrapers exist because attack-surface work needed them. They are on the Apify Store, pay-per-result, no API key — the same tooling, not a marketing version of it.
Subdomain Finder
Enumerates subdomains from Certificate Transparency logs — the hosts a scope statement never lists.
Certificate Transparency Monitor
Watches CT logs daily, so a newly issued certificate tells you about a host the day it appears.
Bulk DNS Records Lookup
Resolves A, CNAME, MX, TXT, NS and CAA in bulk — dangling CNAMEs and stale delegations surface here.
Bulk WHOIS / RDAP
Registrar, creation and expiry dates across a domain portfolio — ownership boundaries and forgotten renewals.
Bulk URL Status Checker
Status codes, redirect chains and final URLs at scale — where a path lands is often the finding.
Tech Stack Detector
Fingerprints CMS, framework, analytics and hosting in bulk, which is what turns a CVE feed into a shortlist.
HTTP Security Headers
CSP, HSTS, frame and content-type policy across thousands of URLs, scored — a map of where the defences thin out.
SSL / TLS Checker
Expiry, issuer, SANs and TLS versions in bulk. The SAN list alone routinely widens a scope.
Wayback URL Extractor
Every archived path for a domain, including endpoints that were removed from the live site but never turned off.
Sitemap to URL Crawler
Walks nested sitemaps into a flat URL inventory — the cheapest complete view of what an app publishes.
CVE Advisory Monitor
NVD, GitHub Advisory and OSV merged into one daily feed with CVSS and affected versions.
Bulk Screenshot Capture
Renders hundreds of hosts headlessly, so a login panel or a forgotten staging box is visible at a glance.
The constraints are the job
Research that ignores these is not research, it is an incident. Every one of them is applied to logiover’s own systems as readily as to anyone else’s.
- Only assets that are in scope for a published program, or that we own ourselves.
- No denial of service, no volumetric or stress testing, no attack on availability.
- No social engineering, no phishing, and no contact with staff or users of a target.
- Automation stays rate-limited and identifiable; recon is read-only traffic that any browser could send.
- Access is proven to the minimum depth needed to establish impact, then stopped. Data is never exfiltrated in bulk.
- Third-party data encountered by accident is not read, not copied, and reported as part of the finding.
- Evidence lives only as long as triage needs it, and is deleted when the report closes.
- Nothing is published before a fix ships and the program agrees — no exceptions for a good writeup.
Found something in logiover?
Report it and it gets fixed — that is the whole policy. In scope: logiover.com,
its subdomains, and the actors published under logiover on the Apify Store.
Out of scope: the Apify platform itself, which has
its own program,
and anything that needs a denial-of-service, a social-engineering attempt, or another
person’s data to demonstrate.
- · Email [email protected] with
[SECURITY]in the subject. - · Include the affected URL, the request sequence, and what an attacker gets out of it.
- · Reports are acknowledged within three business days and you are told when the fix ships.
- · Please keep it private until then. Credit is given in the fix note if you want it; there is no cash bounty.
- · Acting in good faith under this policy means no legal action from us. That is a commitment, not a courtesy.