We assessed server-side validation in web and API functions and built an environment for repeatedly testing the responses and tool execution of AI used in business workflows.
Project overview
Objective
Assess input validation and AI workflows in enterprise software
Scope
File uploads · Password changes · Test automation for business AI
Deliverables
Reproduction evidence and remediation recommendations for web and API vulnerabilities, plus AI test execution and analysis records
From server-side validation to actual AI execution.
For file uploads and password changes, we compared input restrictions in the interface with server-side processing and identified vulnerabilities that allowed validation to be bypassed.
For business AI, we connected login, document uploads and AI execution. We collected responses, tool calls and resulting data changes, and designed the process to compare automated analysis with execution records.
Client and product identifiers have been removed. Technical examples have been reconstructed for explanation and reflect observations made during a past assessment. They do not indicate the client's current security status or whether remediation has been completed.
Assessment details
Select an item to review the assessment process and technical evidence.
File upload validation＋
05FILE UPLOAD / INPUT VALIDATIONSwiss CRM software · Anonymised case
An upload request blocked with a single filename attribute was accepted when the same attribute was submitted more than once. We confirmed that this allowed a file with a prohibited extension to be stored.
Risk and impact
The validation and storage stages used different filename values. A file accepted during validation could therefore be stored with a prohibited extension.
Assessment method
A request containing only a prohibited extension was rejected with 403. When an allowed extension and a prohibited extension were submitted in sequence under the same attribute, the upload was accepted with a 200 response.
Remediation guidance
We recommended rejecting duplicate or ambiguous filename values and using the same value for validation and storage. We also recommended explicitly defining allowed extensions and file types on the server, and separately controlling storage locations and filenames.
RETEST CRITERIA
Retest criteria
Verify that prohibited extensions are rejected for both single and duplicate values. The filename that passes validation must match the stored filename, and legitimate files must remain uploadable.
Password policy enforcement＋
06PASSWORD POLICY / API CONTROLSSwiss CRM software · Anonymised case
The password policy was not enforced by the API.
Unlike the input restrictions in the interface, direct API requests accepted short passwords or empty values. Password change requests were also not rate-limited.
Risk and impact
Browser-side input restrictions alone cannot enforce a password policy. Requests sent without using the interface could set weak passwords, and the server lacked controls for repeated calls to the password change function.
Assessment method
Using a test account, we submitted short and empty values to the password change API. We compared whether values blocked in the interface were processed by the server with a 200 response, and also checked rate limits on password change requests.
Remediation guidance
We recommended enforcing the password policy consistently on the server and rejecting empty values and weak passwords. Password change requests should also be subject to appropriate rate limits and attempt logging.
RETEST CRITERIA
Retest criteria
Verify that the interface and API follow the same password policy. Legitimate changes must remain possible, while repeated requests are subject to the agreed limits and recorded in the logs.
Test automation for business AI＋
07AI SECURITY / TEST AUTOMATIONSwiss CRM software · Project case study
AI responses and tool execution were tested within actual business workflows.
We built an automation environment for repeatedly testing business AI assistants. It connected login, business data creation, document uploads and AI execution, and was designed to verify responses, tool calls and resulting data changes.
Implementation objective
Model responses alone do not adequately reveal how a service enforces permissions or carries out business processes. We designed tests to run through the application's standard interfaces and examine the interactions between documents, user permissions and tools.
Assessment scope
The checks covered prompt injection in documents, free-text input and metadata; system prompt disclosure; data isolation between organisations; tool misuse; and parameter manipulation. Separate reliability tests were designed to assess factual accuracy, consistency and adherence to the required response format.
Review of analysis results
We combined canary markers for detecting disclosure, LLM-based evaluation and rule-based analysis. Findings flagged by automated analysis were checked directly against response and tool-call records, so that only substantiated findings would be included in the final analysis.
DELIVERABLES
Records for development team retesting
We recorded version-specific inputs and expected behaviour alongside requests, responses, repeated test results and tool calls. The process was designed to verify automated judgements and include substantiated evidence in the analysis report.
