Aramon carried out a gray-box security assessment of the NearTest web application over a five-day engagement. Testing focused on authentication, authorization and session handling across the customer-facing application and its administrative console. Two critical and two high-severity findings allow an authenticated standard user to reach administrative functionality, and are the priority for remediation.

Assess the security posture of the NearTest web application and its supporting API from the perspective of an authenticated standard user, with emphasis on access control between user roles.

The assessment followed a standard web application testing methodology covering reconnaissance, authentication and session testing, authorization and access control testing, input validation, and configuration review, aligned with the OWASP Web Security Testing Guide.

The support ticket attachment feature accepts HTML and SVG uploads without validating their content type. A standard user can attach a file containing JavaScript that executes in an administrator's browser when the ticket is opened, in the security context of the application.

An attacker with a standard account can hijack an administrator's session and gain full administrative access, without needing the administrator's credentials.

Reject HTML and SVG uploads in the ticketing system, enforce a strict allow-list of file types, serve uploaded content from a separate cookieless origin, and apply a Content Security Policy to the admin console.

The endpoint used to change a user's role does not verify that the requesting session belongs to an administrator. Any authenticated user can call it directly and set their own account to the administrator role.

Complete compromise of the application's access control model. Any registered user can become an administrator without an exploit chain.

Enforce server-side role checks on every administrative endpoint, never rely on the client to hide administrative functionality, and log role changes for review.

Customer invoices are retrieved using a sequential numeric identifier. The application does not verify that the requesting user owns the requested record, so any authenticated customer can view other customers' invoices by changing the identifier.

Any customer can enumerate and read other customers' billing information and personal details.

Verify object ownership on every request, use non-sequential identifiers where practical, and add authorization tests for resource-level endpoints.

Several administrative actions, including deleting published content, are only restricted in the interface. The underlying API accepts requests from any authenticated session regardless of role.

A standard user can delete or modify content that should only be manageable by administrators, affecting data integrity for all users.

Apply the same authorization checks used in the interface to the underlying API, and add automated tests asserting non-admin accounts receive a 403 response.

The password recovery endpoint returns a different message depending on whether the submitted email address is registered, allowing an attacker to build a list of valid accounts.

An attacker can enumerate valid accounts and use the list for targeted phishing or credential stuffing.

Return an identical response regardless of whether the account exists, and rate-limit the endpoint.

The endpoint used to change a user's registered email address does not include or validate an anti-CSRF token, and accepts requests based on the session cookie alone.

An attacker can change a victim's registered email as a step toward taking over the account through password recovery.

Implement anti-CSRF tokens on state-changing requests and validate the Origin header as a secondary control.

Unhandled exceptions return a full stack trace to the client, including internal file system paths and the framework version.

Internal paths, dependency versions and application structure are disclosed, aiding further attacks.

Return a generic error message to the client in production and log full details server-side only.

The application accepts passwords as short as four characters with no complexity requirement, and does not check submitted passwords against known-breached password lists.

Weak passwords increase the likelihood of successful credential stuffing and brute-force attacks.

Enforce a minimum password length and check new passwords against a breached-password list.

The Server header returned by the application discloses the exact web server software and version in use.

Version disclosure lets an attacker check for known vulnerabilities affecting that specific version.

Remove or genericize the Server header at the web server or reverse proxy level.

Responses do not include recommended security headers such as Content-Security-Policy, X-Content-Type-Options or Strict-Transport-Security.

The absence of these headers removes a layer of defense against content sniffing, clickjacking and downgrade attacks.

Add the recommended security headers at the application or reverse proxy level.

Response headers and publicly served source maps reveal the frameworks, libraries and versions used to build the application.

Knowledge of the technology stack helps an attacker focus on known vulnerabilities affecting those components.

Remove identifying headers and avoid deploying source maps to production.

A diagnostic endpoint is publicly reachable without authentication. It does not expose sensitive data but confirms internal service names and uptime.

Minimal on its own, but combined with other findings it helps an attacker understand the application's internal structure.

Restrict the endpoint to internal networks or authenticated monitoring systems.