SECTION OVERVIEW
Fifteen ways in. We check all of them.
Every engagement — regardless of tier — is tested against the same fifteen categories, grouped below by what they let an attacker actually do.
Injection & execution
Attacks that get the target system to run code or logic it never should have.
Remote code execution
Lets an attacker run their own commands on your server, usually by exploiting an input the application trusted without checking it. Once achieved, it typically hands over control of the whole system, not just the vulnerable feature. It’s the category we prioritize first, since almost every other weakness can be reached through it.
Local code execution
Lets someone who already has a foothold on a system run arbitrary code on that host to go further. It’s usually the second step after a smaller win, like a leaked credential or a misconfigured service. A minor entry point can turn into a full compromise if this path is open behind it.
Local file inclusion
Tricks an application into loading a file it shouldn’t, usually by manipulating a filename or path parameter. This can expose configuration files, credentials, or source code, and can sometimes be chained into remote code execution.
Cross-site scripting (XSS)
Lets an attacker inject a script into a page that other users then load in their own browser. It’s typically used to steal session cookies, impersonate a logged-in user, or alter what the victim sees.
SQL injection & other injection attacks
Lets an attacker manipulate a database query by inserting their own logic into a field the application trusted. Depending on the database’s own permissions, this can expose or alter everything it holds.
Identity & access
Attacks that let someone act as a user they aren’t, or do more than their role allows.
Broken authentication
Covers any weakness in how a system verifies who a user actually is — weak password rules, predictable session tokens, or a login flow that can be bypassed outright.
Cross-account accessibility
Checks whether one user can reach or change another user’s data just by altering an ID or reference in a request. It’s an authorization flaw rather than an authentication one: the login works exactly as designed.
Privilege escalation
What happens when a user, or an attacker posing as one, reaches access above their intended level — a regular account hitting admin functions, for example. It can run vertically or horizontally.
Cross-site request forgery (CSRF)
Tricks a logged-in user’s browser into submitting a request they never intended to make, riding on the session they already have open. It relies on the trust a site places in the browser.
Infrastructure & exposure
Weaknesses in what’s exposed at the edge of your infrastructure, not just inside your application.
Server-side request forgery (SSRF)
Lets an attacker make your own server send requests to destinations it shouldn’t be able to reach, including internal systems never meant to face the internet. It’s often used to pivot inward.
Exposed secrets
Credentials, API keys, or tokens sitting somewhere they can be read without authorization — a public repository, a client-side script, an unprotected config file. A single exposed secret can undo every other control.
Dangling DNS
Happens when a DNS record still points to a resource — a cloud service, a subdomain, a third-party platform — that no longer exists or is no longer owned by you.
Subdomain / domain takeover
What dangling DNS makes possible: an attacker registering or claiming an abandoned resource so your own domain ends up serving their content.
Unrestricted file upload → reverse shell
Happens when an application accepts a file without properly checking its type, its content, or where it gets stored and executed.
Data exposure
Whether the personal data you need to protect is reachable by anyone who shouldn’t have it.
Leaked personal information & PII
Checks whether personal or personally identifiable information — names, contact details, government IDs, financial data — is reachable by someone who shouldn’t have access to it. This is the exposure that carries Data Privacy Act consequences.
VERIFICATION
A finding isn’t a finding until we’ve proven it
Nothing reaches your report on a scanner’s word alone
Automated tools flag matches, not vulnerabilities — and a raw match list is full of noise: paths that don’t actually exist, logins that don’t actually work, patterns that look dangerous but aren’t reachable.
- Every category above is checked by a person, not just a scanner.
- Where Hiraya surfaces a candidate, a tester reproduces it and checks the impact before writing it up.
- If we can’t prove it, it doesn’t go into your report.