Cybersecurity & Application Assurance
Security testing for web, API and AI applications
Understand how your application enforces permissions, handles untrusted input and protects its workflows. I combine manual penetration testing, targeted tools and full-stack engineering to validate weaknesses and connect findings to practical fixes.
With your authorization and within an agreed scope, I test how your application controls access, handles untrusted input and protects its workflows. I confirm which weaknesses are real and explain how to fix them. When retesting is included, I check the fix.
- Web, API and AI applications
- Manual testing with targeted tools
- Validated findings and evidence
- Remediation guidance
- Retesting, when included
- Testing only after authorization
For legal-tech, AI and B2B software teams that need a defined assessment or help remediating application weaknesses.
The report excerpt, walkthrough and examples on this page use a fictional application and fictional findings. They are not client findings. Real client assessments stay under NDA.
Finding 01 · Demo App
Another tenant’s documents readable through the API
Scope record
- Area
- Access control and tenant isolation
- Roles
- Admin (demo), Member (demo)
- Environment
- Staging (demo)
Reproduction
Signed in as Member (demo), Tenant A
GET /api/Expected: access refused · Observed: Tenant B document returned
Impact and priority
Priority: High (example)Members of one customer account can read another account’s documents.
Remediation guidance
Check on the server that each requested document belongs to the signed-in user’s tenant.
Example report structure — not client findings
What you receive
- 1. Scope record
- The application areas, roles and conditions actually assessed.
- 2. Validated findings
- Affected behavior, reproducible steps and relevant evidence, with sensitive material handled appropriately.
- 3. Impact and priority
- An explanation of what the weakness enables and why it matters in this system.
- 4. Remediation guidance
- Practical changes for the relevant application layer.
- 5. Retest results, when included
- Whether the reported behavior is resolved, partially resolved or still reproducible, and any remaining limits.
Start here · No technical background needed
How an assessment works, in four steps
An assessment answers a specific question about your application, within limits agreed in advance.
- 01
Agree what to test
We agree the application, the workflow, the user roles and the question to answer, and confirm that testing is authorized.
- 02
Test it
I examine the agreed workflow by hand, with tools in support, looking for ways around its rules and protections.
- 03
Confirm what is real
Relevant possible issues are examined by hand to confirm whether they are real and what they allow.
Manual validation
- 04
Report, fix and check again
You receive a report with the findings and recommended fixes. Your team makes the fixes, or I do when implementation is within the agreed scope. When retesting is included, I check the changed behavior.
Think of it as a commissioned inspection of agreed rooms in a building. The inspector tries the doors the way different people would, records which ones open when they should not, recommends repairs and, if agreed, comes back to check them. The report covers the rooms inspected, not the whole building, and it is not a certificate.
Why it matters
What an assessment helps you understand
An assessment looks at how your application enforces permissions, handles untrusted input and protects its workflows, then connects what it finds to practical fixes.
The challenge
- It is hard to know whether users, roles and customer accounts can reach records or functions beyond their permissions.
- Login, recovery and sensitive account changes need checking for ways they could be misused (abuse paths), not only their normal use.
- AI features that read untrusted content need checking for whether that content can redirect them.
- Tools point to possible issues; someone still has to confirm whether the relevant ones are real, exploitable and important in your system.
What an assessment provides
- A defined scope: the application areas, roles and conditions actually assessed.
- Validated findings with reproducible steps, relevant evidence and an explanation of impact.
- Practical remediation guidance for the relevant application layer.
- Retesting of the changed behavior, when included, and implementation of fixes when it is within the agreed scope and access.
Example questions
Three questions an assessment can answer
These are assessment questions, not findings about your product.
Question 1
Can a user reach another customer’s records or restricted functions by making requests directly?
- Access control and tenant isolation
Question 2
Can an application action happen without the required state, permission or approval?
- Business logic
Question 3
Can untrusted content redirect an AI feature beyond its intended task or permitted information?
- AI and LLM features
Interactive walkthrough · Fictional example
Follow one assessment from scope to retest
Step through a fictional assessment of a made-up application to see what happens at each stage. Each step has a plain-language explanation and a technical note.
Step 1 of 5
Agree what to test and why
We choose the part of the application to examine and the question it should answer. In this fictional example: can a member of one customer account reach another customer’s documents by sending requests directly?
Under the hood
Define the target and objective: the relevant application, workflow, roles and assessment question. Here the coverage is access control and tenant isolation, including object-level and function-level authorization and direct API access.
- Scope
- Roles
- Tenant isolation
- Object-level authorization
Target
- Application
- Demo App web application and API
- Workflow
- Shared documents
- Roles
- Admin (demo), Member (demo)
- Customer accounts
- Tenant A, Tenant B (test data)
Assessment question
Can a Member in Tenant A reach Tenant B’s documents by direct request?
Not in scope
- Production environment
- AI feature (demo)
Step 2 of 5
Agree access and testing boundaries
Before any testing, we agree that it is authorized, which environment and test accounts to use, which methods are allowed and how evidence will be handled. A staging copy of the application with test accounts is often the practical starting point.
Under the hood
Authorization, test accounts, environment, permitted methods and handling of evidence are established before testing. Production testing requires explicit scope and authorization.
- Authorization
- Staging environment
- Test accounts
- Evidence handling
Agreed before testing
Agreed (demo)- Testing authorized by the application owner (demo)
- Environment: staging (demo)
- Test accounts: two tenants, two roles each
- Permitted methods: manual testing and agreed tools
- Evidence: handled as agreed, test data only
- Production: not included
Step 3 of 5
Investigate and confirm what is real
I work through the agreed workflow by hand, with tools supporting the search. When a tool or a test points to a relevant possible issue, I examine it by hand. I check whether it is real, whether it can be exploited and what it means for the application.
Under the hood
Manual testing with relevant tools, then confirmation of the practical impact of meaningful findings. In this example, direct API requests made as one tenant test object-level authorization on another tenant’s records.
- Manual testing
- Direct API requests
- Validation
- Reproduction
Tool flag
Not reproducedPossible XSS: search text shown back on the page (demo)
Checked by hand: the text is encoded, so it does not run as script in this test.
Direct request
ReproducedSigned in as Member (demo), Tenant A
GET /api/- Expected:
- access refused
- Observed:
- Tenant B document returned
Step 4 of 5
Report what was found and how to fix it
The report records what was tested, each validated finding with the steps to reproduce it, why it matters in your system and the recommended fix. It also states the limits of the testing.
Under the hood
Findings include the affected behavior, reproducible steps and relevant evidence, with sensitive material handled appropriately. Priority explains what the weakness enables in this system; remediation guidance targets the relevant application layer.
- Reproduction steps
- Evidence
- Impact and priority
- Remediation guidance
Scope record
Access control and tenant isolation · Shared documents workflow
Validated findings
- F-01 · Another tenant’s documents readable through the APIPriority: High (example)
- F-02 · Tenant B document titles returned by the search APIPriority: Medium (example)
Limits
Production and the AI feature were not in scope (demo). Results apply to the tested scope.
Step 5 of 5
Check the fix
In this example, retesting is included. After the agreed fix is made (by your team, or by me when that is in scope), I repeat the original test. I also check nearby behavior the change could affect. Each result says whether the issue is resolved, partially resolved or still reproducible.
Under the hood
Retesting checks the original behavior and relevant regressions after correction. A passed retest confirms the observed behavior within its tested scope; it does not establish that all application risks have been eliminated.
- Retest
- Regression check
- Tested scope
- F-01 · Another tenant’s documents readable through the APIResolved
The same request is now refused (demo).
- F-02 · Document titles in searchPartially resolved
Search no longer returns them, but the recent-documents request still does (demo).
- Regression checkNo regression found
Admin (demo) access to Tenant A documents still works as intended.
Results apply to the tested scope only.
Step 1 of 5: Agree what to test and why
Every screen in this walkthrough is an illustration made for this page, with a fictional application and fictional findings. None is a product screenshot or a client finding.
Free first review
Start with one application workflow
Have a specific concern about tenant access, an account flow, a document operation or an AI feature? The first review is free. Its size depends on your application and the question you need answered, and we confirm both before anything is checked.
If the review finds issues, fixing them can become the next piece of work. Larger or more complex workflows are scoped and quoted as a full assessment; smaller ones can start with a short trial engagement. Testing begins only after authorization and an appropriate environment are agreed. The result may be that no issue is found within the tested scope.
Request a free first review(opens in new tab)Included
- One agreed question, sized to your application
- A brief record of what was checked
- Validated observations and suggested next steps
This review is not
- A full penetration test
- Compliance certification
- Assurance that an entire application is secure
What I assess · For technical readers
Coverage selected for your application
Web applications and APIs
Inputs, endpoints, request handling, files and server behavior. Testing may cover injection, XSS, SSRF, path traversal and related weaknesses where relevant to the agreed application.
- Injection
- XSS
- SSRF
- Path traversal
Access control and tenant isolation
Whether users, roles and tenants can access or modify records, documents or operations beyond their permissions. Coverage includes object-level and function-level authorization and direct API access.
- Object-level authorization
- Function-level authorization
- Direct API access
Authentication and accounts
Login, recovery, verification, sessions, token handling and sensitive account changes. The assessment follows the actual account flows and their abuse paths.
- Login and recovery
- Sessions
- Tokens
Business logic
Workflow bypasses, unauthorized state transitions, repeated operations, concurrent requests and inconsistencies in application rules.
- State transitions
- Repeated operations
- Concurrent requests
AI and LLM features
Direct and document-based prompt injection, untrusted-content handling and application permissions around AI-driven functionality.
- Prompt injection
- Untrusted content
- Application permissions
Configuration and exposed assets
Relevant services, web configuration, TLS, storage permissions, signed URLs and dependency exposures within the agreed application scope.
- TLS
- Storage permissions
- Signed URLs
- Dependency exposures
Security-focused QA
Boundary conditions, malformed payloads, validation gaps, file restrictions, data consistency and regressions with security implications.
- Malformed payloads
- Validation gaps
- File restrictions
Reporting and remediation
Validated findings, reproduction evidence, impact, proposed corrections and retesting of the changed behavior.
- Evidence
- Remediation
- Retesting
Coverage is selected for the application, available access and agreed objectives. A list of testing techniques is not a claim that every technique applies to every system.
For technical readers · Conceptual view
Where each assessment area applies
A typical web, API and AI application, showing which parts each assessment area examines. Coverage for your application follows its actual architecture and the agreed scope.
Part 1: Who is asking
People and roles
- Users and roles
- Customer accounts (tenants)
- Sessions and tokens
- Authentication and accounts
- Access control and tenant isolation
Part 2: Entry points
Web application and API
- Pages and forms
- API endpoints
- File uploads
- Web applications and APIs
- Security-focused QA
Part 3: Rules
Permission and logic checks
- Object-level and function-level authorization
- Workflow state and approvals
- Repeated and concurrent requests
Where the application decides who can do what
- Access control and tenant isolation
- Business logic
Part 4: Stored information
Data and files
- Customer records
- Documents and storage
- Signed URLs
- Access control and tenant isolation
- Configuration and exposed assets
Part 5: Outside input to the AI
Untrusted content the AI reads
- Text typed by users
- Uploaded or retrieved documents
- AI and LLM features
Part 6: AI feature
AI-driven functionality
- Prompts and instructions
- Information it can reach
- Actions it can trigger
- Requests pass through the permission checks
- AI and LLM features
Part 7: Around the application
Configuration and exposed assets
- Relevant services
- Web configuration and TLS
- Storage permissions
- Dependency exposures
- Configuration and exposed assets
How the work proceeds
Agree the scope. Investigate. Report. Retest.
Each stage produces a defined output. The remediation step between the report and the retest is agreed for each engagement.
Stage 1: Define the target and objective
Agree the relevant application, workflow, roles and assessment question.
- Output
- Assessment question and scope
Stage 2: Agree access and testing boundaries
Establish authorization, test accounts, environment, permitted methods and handling of evidence.
- Output
- Authorization, test accounts and environment
Stage 3: Investigate and validate
Use manual testing and relevant tools, then confirm the practical impact of meaningful findings.
Manual validation
- Output
- Validated findings
Stage 4: Report and prioritize
Explain the assessed scope, validated issues, limitations and recommended fixes.
- Output
- Report with remediation guidance
Stage 5: Retest agreed changes
Check the original behavior and relevant regressions after correction.
- Output
- Retest results, when included
Between report and retest: remediation
- Your own engineering team can use the findings.
- I can make agreed code or configuration corrections when implementation is within the agreed scope and access.
- Where independent assurance is required, a separate reviewer can assess the remediation.
Assessment decisions
Decisions that shape an assessment
Six choices that keep results specific to your application and clear about their limits.
Manual testing, supported by tools
Tools support discovery and investigation. Relevant findings are manually examined for validity, exploitability and application impact.
- Manual testing
- Tool-assisted discovery
Coverage chosen for the application
Areas and techniques are selected for the application, available access and agreed objectives.
- Scope
- Objectives
Staging and test accounts as a starting point
The environment and methods are agreed before testing. A suitable staging setup with test accounts is often the practical starting point. Production testing requires explicit scope and authorization.
- Staging
- Test accounts
- Production by agreement
Impact explained for this system
Impact and priority explain what the weakness enables and why it matters in this system.
- Impact
- Priority
Sensitive material handled appropriately
Handling of evidence is agreed before testing. Findings include relevant evidence, with sensitive material handled appropriately.
- Evidence handling
Retest the change and related behavior
When included, retesting checks the original behavior and relevant regressions after correction, and records any remaining limits.
- Retest
- Regression check
Limits
What an assessment does and does not establish
Results describe the behavior observed within the agreed and tested scope.
An assessment can establish
- Validated findings within the agreed and tested scope
- A record of the application areas, roles and conditions actually assessed
- Whether reported behavior is resolved, partially resolved or still reproducible, when retesting is included
It does not establish
- That an entire application is secure
- That all application risks have been eliminated, even after a passed retest
- Compliance certification
The report excerpts and screens on this page are illustrations with fictional data, and the questions are examples. None is a finding about your product or any client’s application.
Track record
Client assessments, kept confidential
I have delivered security assessments for client applications, including teams in Poland and in Texas, USA. Client names, systems and findings stay under NDA, which is why the examples on this page are fictional.
Related engineering work: Explore an implemented intake workflow and its engineering scope, review controls and confidentiality boundaries. This is engineering evidence; it does not document an application security assessment or its findings.
Read the intake case studyFAQ
Security assessment questions
Is this only automated scanning?
No. Tools support discovery and investigation. Relevant findings are manually examined for validity, exploitability and application impact.
Can you fix the issues you identify?
Yes, when implementation is within the agreed scope and access. I can work in the application code or provide findings to your team, then retest the changed behavior.
Do you test production?
The environment and methods are agreed before testing. A suitable staging setup with test accounts is often the practical starting point. Production testing requires explicit scope and authorization.
Does a passed retest mean the product is completely secure?
A retest confirms the observed behavior within its tested scope. It does not establish that all application risks have been eliminated.
Glossary
Terms used on this page
Plain-language definitions for readers from legal, business and technical backgrounds.
Testing and scope
- Penetration testing
- Authorized testing that looks for weaknesses the way an attacker might, then confirms which ones are real, within an agreed scope.
- Manual testing
- Testing carried out by a person reasoning about how the application should behave, with tools in support.
- Tool-assisted discovery and tool flag
- Using automated tools to point to possible issues. A tool flag is one such possible issue, which still has to be checked by hand.
- Scope
- The parts of the application, user roles, environment and methods agreed for testing. Results apply only to that scope.
- Authorization (two meanings)
- The application owner’s permission for testing, agreed before it begins; and, inside an application, how it decides what a signed-in user may see or do.
- Staging and production
- Staging is a separate version of the application used for testing, normally without real users. Production is the live system that real users rely on.
- Test account
- An account created for testing, separate from real users’ accounts.
- Security-focused QA (quality assurance)
- Quality testing aimed at security: boundary values, malformed input, file restrictions and validation gaps.
- Full-stack engineering
- Work across all parts of an application, from the screens people use to the server, data and configuration behind them.
- Independent assurance
- A check by a reviewer who did not make the change being reviewed.
- Compliance certification
- A formal attestation against a standard or regulation, issued through that standard’s own process. The testing on this page is not a certification.
Users, access and accounts
- Role
- A set of permissions given to a type of user, such as an administrator or a member.
- Access control
- The rules that decide which users and roles can reach which records and functions.
- Tenant and tenant isolation
- A tenant is one customer account in software shared by many customers. Tenant isolation keeps each customer’s data and actions separate from the others. “Cross-tenant” means reaching from one into another.
- Object-level authorization
- Checking that a user may access the specific record they asked for, such as one document, not just that type of record.
- Function-level authorization
- Checking that a user’s role may use a particular function, such as an administrator-only action.
- Application permissions
- The records and actions a feature, including an AI feature, is allowed to reach on a user’s behalf.
- Authentication
- Confirming who a user is, for example through login, verification and account recovery.
- Session and token
- A session keeps a user signed in. A token is a credential the application uses to recognize that session or grant access.
- Abuse path
- A way of using a normal feature, such as login or account recovery, for a purpose it was not meant to allow.
- Credentials and access keys
- Passwords, tokens and secret keys that let people or software reach a system.
How applications work
- API, endpoint and direct API access
- An API is the interface an application’s screens use to read and change data; an endpoint is one address in it. Requests can also be sent to it directly, outside the normal screens.
- Request (GET)
- A request is a message sent to an application’s server. GET is the kind of request that asks to read what is at the address that follows it.
- Server-side check
- A check made by the application’s server rather than in the user’s browser.
- Application layer
- The part of a system where a fix belongs, such as the screens, the API, the server logic, the database or the configuration.
- Business logic and state transitions
- The application’s own rules, such as required steps and approvals. A state transition is a move from one step or status to another; a logic weakness lets someone skip, repeat or reorder steps.
- Concurrent requests
- Several requests sent at the same moment. They can expose inconsistencies when an application does not handle them safely.
- Configuration and exposed assets
- The settings that control how an application is served, and the services, files and settings that can be reached from outside it.
- TLS
- The encryption that protects information travelling between a browser and the application, shown as “https” in the address bar.
- Storage permissions
- Settings that control who can read or change files kept in file storage.
- Signed URL
- A link that gives temporary access to a stored file without signing in. Its permissions and expiry need to be right.
- Dependency exposure
- Risk that comes from third-party software components the application relies on.
Weaknesses and AI features
- Untrusted input and untrusted content
- Input the application did not create itself and cannot assume is safe, such as text typed by users, uploaded files or retrieved documents.
- Validation gap
- A missing check that incoming data has the expected form, size or type.
- Malformed payloads and boundary conditions
- Data sent in a broken or unexpected form, and values at or just beyond the limits an application expects, such as an empty field or a very large file.
- File restrictions
- Rules on which files may be uploaded, such as their type, size or name.
- Injection
- A weakness where untrusted input is treated as part of a command or query the application runs.
- XSS (cross-site scripting) and encoding
- XSS lets untrusted content run as script in another user’s browser. Encoding makes the browser display such content as text instead of running it.
- SSRF (server-side request forgery)
- A weakness that makes the server send requests it should not, such as to internal systems.
- Path traversal
- A weakness that lets a request reach files outside the location the application intended.
- LLM
- Large language model: the kind of AI model behind many chat and text features.
- Prompt injection
- Instructions placed in user input (direct) or in a document the AI reads (document-based) that try to steer an AI feature away from its intended task.
Findings and reports
- Validated finding
- A weakness that has been reproduced and whose practical impact has been confirmed, rather than a possible issue reported by a tool.
- Evidence and evidence handling
- In a security report, evidence means records such as requests, responses or screenshots that show how a finding was reproduced. Evidence handling is how those records are stored, shared and limited.
- Reproduction steps
- The exact steps that make a weakness happen again, so others can confirm it and later check a fix.
- Exploitability
- Whether, and how readily, a weakness can actually be used to cause harm.
- Impact and priority
- Impact describes what a weakness allows someone to do. Priority indicates how soon it should be addressed relative to other findings.
- Remediation
- The change that corrects a weakness, in code, configuration or process.
- Retest, regression and regression check
- A retest repeats the original test after a fix. A regression is something that worked before but breaks, or becomes unsafe, after a change; a regression check looks for such breaks.
Capability area 03 / 04
Other capability areas
Security testing is one of four areas I work across, often in the same engagement. See all capabilities.
- Area 01 · 4 capabilities
Organizational knowledge & legal intelligence
Firm guidance, case context and reviewable recommendations.
- Area 02 · 10 capabilities
Legal workflows & integrations
Intake, documents and case work, integrated.
- Area 04 · 5 capabilities
Product & systems engineering
Full-stack platforms with production architecture.
Define the security question you need answered
Share the type of application, the workflow you are concerned about and whether you need an assessment, remediation, or both. We can agree the next step from there.
Discuss a security assessment(opens in new tab)Choose a time on Calendly.
Prefer email? hkhantanoli@gmail.com(opens in new tab)
What to share
- The type of application
- The workflow you are concerned about
- Whether you need an assessment, remediation or both
Please leave out passwords, access keys and sensitive data. Access and testing boundaries are agreed before any testing begins.