How CyberZEALS identified critical authorization, file access, request integrity, and account security weaknesses in a private customer portal supporting three levels of role-based access.
AUTHORIZED TESTING | BURP SUITE | CUSTOM SCRIPTS | BUSINESS LOGIC | TENANT ISOLATION
Confidential public case study: The client name, application name, domains, account identities, endpoint names, payloads, and exposed secret values are withheld. Testing was authorized by the client and limited to its application and approved customer tenant environments.
01 Case Study Snapshot
The numbers that defined the engagement
| Field | Result |
|---|---|
| Application | Private multi-tenant portal for customer data, dashboards, charts, reports, and assets |
| Access model | 3 roles: Normal User, Company Admin, and Super Admin |
| Security findings | 11 consolidated findings |
| Severity | 3 Critical, 1 High, 6 Medium, and 1 Low |
| IDOR exposure | 38 affected endpoints with cross tenant access or modification risk |
| Testing approach | Manual testing with Burp Suite and purpose built custom scripts |
02 Client Security Challenge
A private application still requires strong protection between every customer and role
The application provided customers with access to internal information, dashboards, charts, reports, documents, and managed assets. It used three permission levels, but the real security requirement was more complex than login protection: every request needed to preserve both the user’s role and the customer tenant boundary.
- Normal Users needed access only to their assigned information and permitted workflows.
- Company Admins needed administrative control inside their own organization without gaining platform privileges.
- Super Admin operations required stronger authentication, protected account changes, and reliable auditability.
- Reports, charts, assets, documents, alerts, activities, and profile records created many object references requiring server side ownership checks.
03 Authorized Assessment Scope
Testing remained within client approved systems and accounts
| Scope area | Coverage |
|---|---|
| Included | The private customer portal, supporting APIs, three approved role types, and designated customer tenant environments |
| Primary focus | Tenant isolation, role authorization, authentication, sessions, business logic, input handling, and sensitive data exposure |
| Excluded | Unrelated third party systems, public users, destructive production activity, and disclosure of client specific exploit details |
04 Manual Testing Approach
Analyst led testing examined how the application behaved across roles tenants and workflows
| Testing area | How it was assessed |
|---|---|
| Application mapping | Burp Suite captured browser and API traffic to identify important functions, objects, parameters, and trust boundaries. |
| Role based testing | Normal User, Company Admin, and Super Admin behavior was compared to identify horizontal and vertical privilege failures. |
| Tenant isolation | Customer owned objects were tested to determine whether server side controls consistently enforced company ownership. |
| Business logic | Sensitive workflows were reviewed for unsafe sequences, account changes, impersonation, report operations, and administrative abuse. |
| Authentication and sessions | MFA, password recovery, login controls, logout, password changes, token lifetime, and concurrent sessions were assessed. |
| Input and file handling | User controlled input, browser security controls, redirects, file access behavior, and client side secrets were examined. |
| Custom automation | Purpose built scripts repeated authorization checks across object and role combinations to validate the breadth of exposure. |
Why manual testing mattered. The most serious weaknesses depended on application specific relationships between users, tenants, reports, assets, and administrative roles. These issues required human analysis and could not be reliably understood through automated scanning alone.
05 Findings By The Numbers
The assessment identified concentrated risk in authorization request integrity and sensitive file access
| Severity | Count | Security theme |
|---|---|---|
| Critical | 3 | Cross tenant access, exposed configuration secrets, and unsafe state changing workflows |
| High | 1 | Stored and reflected browser side script execution |
| Medium | 6 | Privilege, MFA, session, API key, rate limiting, and redirect weaknesses |
| Low | 1 | Browser security header and CORS hardening gaps |
| Total | 11 | Consolidated security findings |
Critical exposure summary
| Scale | Critical finding | Business risk |
|---|---|---|
| 38 endpoints | Cross tenant IDOR | Insufficient object authorization allowed authenticated users to reach or modify information belonging to other customers. |
| 1 finding | Path traversal | A file access weakness exposed web.config, including database credentials, internal keys, API keys, and other application secrets. |
| Application wide | CSRF and unsafe methods | State changing workflows lacked consistent request integrity protections, creating unauthorized action risk across the portal. |
06 Additional Security Findings
Supporting weaknesses increased the likelihood and impact of account and browser based attacks
| Count | Finding | Potential impact |
|---|---|---|
| 1 High | Stored and reflected XSS | Attacker controlled input could execute in a user’s browser across multiple application locations. |
| 1 Med | Administrative privilege escalation | Company and platform administration workflows allowed unsafe control over more privileged identities. |
| 1 Med | Weak MFA | OTP attempts were insufficiently invalidated or limited, while privileged MFA enforcement was incomplete. |
| 1 Med | Persistent sessions | Sessions remained valid after logout or password changes and used an excessive lifetime. |
| 1 Med | Exposed API key | A browser visible integration key lacked sufficiently restrictive usage controls. |
| 1 Med | Password reset abuse | Missing rate limits enabled automated reset requests, user harassment, and email flooding. |
| 1 Med | Open redirect | An untrusted login return value increased the credibility of phishing campaigns. |
| 1 Low | Headers and CORS | Missing browser security headers and permissive CORS weakened defense in depth. |
07 Business Logic Risks Tested
Testing extended beyond common vulnerabilities to the application’s customer and administrative workflows
| Risk area | Examples of coverage |
|---|---|
| Tenant isolation | Cross customer access to reports, dashboards, documents, alerts, actions, datasets, activities, and profile information |
| Object ownership | Unauthorized viewing, editing, deletion, sharing, and configuration changes through manipulated object references |
| Role enforcement | Normal User access to administrative actions and Company Admin access to protected Super Admin functions |
| Account security | Email changes, account takeover paths, impersonation, password policy, reset abuse, and privileged MFA requirements |
| Report workflows | Report access, sharing, deletion, chart settings, filters, fields, groups, totals, and dataset boundary enforcement |
| Session security | Logout, password change revocation, concurrent sessions, token lifetime, OTP retries, and password spraying resistance |
| Request integrity | CSRF protections, safe HTTP methods, trusted redirects, input validation, browser controls, and secure file handling |
08 Business Impact
The confirmed weaknesses could combine into broader compromise scenarios
| Business risk | Potential outcome |
|---|---|
| Customer data exposure | IDOR across 38 endpoints could allow one authenticated customer to access or change another customer’s information. |
| Backend compromise | Exposed configuration secrets could provide access to databases, internal services, or third party integrations if credentials remained active. |
| Administrative takeover | Privilege and account change weaknesses could allow a lower privileged administrator to gain control of a protected account. |
| Unauthorized actions | Application wide CSRF weaknesses could cause a signed in user to perform sensitive operations without intending to do so. |
| Browser compromise | Stored or reflected XSS could execute attacker controlled code in a victim’s authenticated browser session. |
| Phishing and abuse | Open redirects, reset flooding, weak MFA, and long lived sessions could reinforce social engineering and account attacks. |
Marketing takeaway. A secure login did not guarantee secure customer isolation. Testing the relationships between roles, tenants, objects, and workflows revealed business critical risks that conventional automated scanning could miss.
09 Remediation Priorities
1 Centralize authorization
Enforce tenant, ownership, and role validation on every object and action, then retest all 38 affected endpoints.
2 Protect secrets and files
Block traversal, remove secrets from web accessible files, and rotate exposed credentials and keys.
3 Secure state changing workflows
Use non GET methods, anti CSRF tokens, secure cookies, origin validation, and consistent request controls.
4 Strengthen privileged accounts
Require MFA, limit OTP attempts, restrict impersonation, protect account changes, and log privileged actions.
5 Improve session and browser defenses
Revoke sessions after security events, remediate XSS, restrict redirects and keys, rate limit recovery requests, and harden headers and CORS.
10 Case Study Outcome
The engagement converted complex application behavior into a focused security roadmap
- Identified 11 consolidated findings across Critical, High, Medium, and Low severity levels.
- Demonstrated that one authorization weakness affected 38 endpoints across customer boundaries.
- Connected one file access weakness to database credentials, internal keys, and API secrets.
- Delivered root cause remediation priorities and a focused security retest plan.
Protect every role and every customer boundary.
CyberZEALS combines manual analysis, Burp Suite, and custom automation to uncover multi tenant authorization, business logic, session, and data exposure weaknesses that automated scanners frequently miss.