Most web applications fail security testing in the same place: not at the login page, but three screens past it, where one role can reach another’s data and nothing about the request looks wrong.
That is the work we do. AppSec Labs has tested authenticated web applications since 2010 — multi-tenant SaaS platforms, financial and payments systems, healthcare portals, internal business applications — for organisations including AT&T, Payoneer, CyberArk, Teva and Bank Hapoalim.
Who this is for
- You are shipping a product that holds other people’s data, and a customer or regulator has started asking how you know it is safe.
- You have run scanners, fixed what they found, and suspect that is not the same as being secure. It is not.
- You are approaching a funding round, an acquisition or an enterprise deal where a credible security assessment is a gate.
- You have a complex role model — admins, partners, tenants, delegated access — and nobody has systematically tried to break it.
What we actually test
The full methodology runs to over a hundred individual checks (the complete list is published here). In practice, the findings that change a release decision cluster in a few areas:
Authorization and multi-tenant isolation
The flaw class we are known for, and the one automated tools cannot see. Every object reference tested against every role: can user A read, modify or delete user B’s records by changing an identifier? Can a tenant reach another tenant’s data through an export, a report, a webhook or a poorly-scoped search? Can a low-privileged role reach administrative functionality directly, bypassing a UI that simply hides the button?
Business logic and workflow abuse
Can steps be skipped, replayed or reordered? Can a price, a quantity or a discount be manipulated between screens? Can a process be completed without a required approval? Can a race condition be used to spend the same balance twice? These are the findings that cost real money, and they exist only in the context of your application — no signature matches them.
Authentication and session management
Credentials transported or stored weakly, account lockout and enumeration, password reset and change flows, “remember me” behaviour, session fixation and timeout, weak or bypassable multi-factor implementations, and tokens that carry more authority than they should. JWTs that trust client-supplied claims are a recurring finding (a real example).
Injection and data validation
SQL, NoSQL, LDAP, ORM, XML, command and template injection; stored and reflected cross-site scripting; HTTP parameter pollution; file upload handling; server-side request forgery. Thorough, but rarely where the interesting findings are in a mature application.
The rest of the surface
Configuration and deployment weaknesses, exposed administrative interfaces, information disclosure through errors and metadata, cryptographic and TLS weaknesses, client-side issues including DOM XSS and clickjacking, CSRF, CORS misconfiguration, web service and API-layer flaws, and denial-of-service exposure where it is in scope.
How the engagement runs
- Scoping. We ask what the application does, who its users are, what would hurt most if it leaked, and how many distinct roles exist. You get a fixed scope, timeline and price — not an open-ended engagement.
- Access. A staging environment that mirrors production, and credentials for every role. Roles matter more than anything else: testing with a single account hides precisely the issues you most want found.
- Testing. Hands-on-keyboard work by experienced testers, accelerated by our own platform, CybeRapid, which takes the repetitive work out of an engagement so more of our time goes on judgement — attack strategy, business context, and what actually matters to you.
- Reporting. Findings written for the person who has to fix them.
- Remediation support. We walk your developers through the report, answer questions while they fix, and review proposed fixes.
- Retest. Every reported finding is retested after the fix, as part of the engagement. It is also where many teams discover a fix was incomplete.
What you receive
- A report with, for each finding: what it is, step-by-step reproduction, the real business impact, and a concrete remediation — not a scanner description and a CVSS number.
- Severity rated by what an attacker can actually achieve in your application. A nominally “medium” issue that exposes another customer’s data is treated as what it is.
- An executive summary that a non-technical stakeholder can act on.
- A walkthrough session with your engineering team.
- A retest report confirming what is genuinely closed — the document your customer or auditor actually wants.
Common questions
How long does a web application penetration test take?
Typically a few days to a few weeks, driven by the number of roles, workflows and integrations rather than by page count. We scope it with you first and commit to the timeline.
Do you test production or staging?
Staging that mirrors production, wherever possible. Where production testing is necessary we agree boundaries in advance – what is in scope, what techniques are excluded, and a contact who can reach us immediately. Destructive testing never happens without explicit written agreement.
What is the difference between this and a vulnerability scan?
A scanner finds known patterns. It cannot tell that this user should not be able to read that record, because nothing about the request is malformed – it is perfectly valid, it simply should not have been answered. Judging that requires understanding what your application is supposed to allow.
Will this satisfy our customer’s security questionnaire or our auditors?
Usually, yes. Our reports are regularly used for enterprise security reviews, SOC 2, PCI-DSS, HIPAA and similar. Tell us which framework or questionnaire you are answering and we will make sure the report addresses it.
How much does it cost?
It depends on scope: application size, number of roles and workflows, whether APIs and mobile clients are included, and how deep you want us to go. We scope properly before quoting, so the number you get is the number you pay.
What do you need from us to start?
A description of the application and what matters most about it, a test environment, and credentials for each user role. That is genuinely it.
Talk to us about testing your web application
Expert-led testing of complex authenticated applications – multi-tenant isolation, authorization/BOLA, business-logic and workflow abuse, complex role models – with developer-usable remediation.
Tell us what the application does and what worries you about it. We will come back with scoping questions, a clear proposal and a realistic timeline — and if a test is not what you need yet, we will say so. Get in touch.
See also: API penetration testing · mobile application testing · AI & LLM application testing · our full methodology.