Twelve common findings

12 findings

• CriticalWeb

  SQL injection

  Untrusted input is concatenated into a database query, so an attacker can change what the query does: read other users' rows, bypass a login, change or delete data and, on some database engines, run commands on the server. It hides in search boxes, filters, sort parameters, API bodies and HTTP headers, not only in login forms.

  Fix: Use parameterised queries or prepared statements everywhere, including ORDER BY and LIMIT values (allow-list those).

• HighWeb

  Cross-site scripting (XSS)

  The application places attacker-controlled text into a page without encoding it for its context, so the browser runs it as script. Stored XSS persists in the database and fires for every visitor, reflected XSS arrives in a crafted link, and DOM-based XSS happens entirely in client-side JavaScript.

  Fix: Encode output for the exact context (HTML body, attribute, URL, JavaScript) and prefer frameworks that do it by default.

• HighAPI

  Insecure direct object reference (IDOR)

  An endpoint takes an object identifier (an invoice number, a user id, a file name) and returns or changes that object without checking that the caller may access it. Changing the identifier in the URL or the request body is enough to reach another customer's data.

  Fix: Authorise every object lookup on the server against the authenticated user, in one shared layer rather than per handler.

• MediumWeb

  Missing security headers

  Responses lack the HTTP headers that switch on browser protections: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, a frame policy (frame-ancestors or X-Frame-Options) and a Referrer-Policy. None of them is a vulnerability alone; they are defence in depth.

  Fix: Set the headers once at the edge (reverse proxy or framework middleware) so every response carries them.

• MediumWeb

  Cross-site request forgery (CSRF)

  A state-changing request (change email, transfer funds, add a user) is accepted on the strength of the browser's cookies alone. A hostile page the victim visits while signed in can submit that request, and the application cannot tell it apart from a real one.

  Fix: Use SameSite=Lax or Strict session cookies and a synchronizer or double-submit token on every state-changing request.

• CriticalNetwork

  Default credentials

  Devices, appliances or software run with the vendor's default username and password, or with a shared password set at install and never changed. The defaults are published in manuals and collected in public lists, so finding them takes seconds.

  Fix: Change every default at install and make it part of the build checklist.

• MediumNetwork

  Weak TLS configuration

  A service still accepts old protocol versions (SSL 3.0, TLS 1.0 or 1.1), weak cipher suites or key exchanges without forward secrecy, or presents a certificate that is expired, self-signed or for the wrong host name.

  Fix: Allow TLS 1.2 and 1.3 only, with AEAD cipher suites and ECDHE key exchange.

• HighNetwork

  Open administrative interfaces

  Management interfaces are reachable from the internet or from user networks: web consoles of firewalls and hypervisors, Jenkins, Tomcat manager, Kubernetes dashboards, Docker APIs, database ports, RDP and SSH. Some require no authentication at all.

  Fix: Put management interfaces on a dedicated management network or behind a VPN, and allow-list the source addresses.

• HighNetwork

  Missing network segmentation

  Networks with different trust levels (user workstations, servers, databases, OT and management) can reach each other freely. There are VLANs on paper, but routing and firewall rules let any host talk to any other on any port.

  Fix: Group systems into zones by trust and function, route between them through a firewall and allow only the flows each zone needs.

• CriticalMobile

  Hardcoded API keys

  API keys, cloud credentials, signing secrets or encryption keys are compiled into the mobile app or shipped in its resources. Anyone can download the app, unpack it and read them with free tools; obfuscation only slows this down.

  Fix: Keep secrets on the server and have the app call your back end, which brokers requests to third parties with its own credentials.

• HighMobile

  Insecure local storage

  The app writes sensitive data (session tokens, personal data, cached API responses, credentials) to shared preferences, plist files, SQLite databases or logs without protection. It can be read from backups, from a rooted or jailbroken device, or by other apps through misconfigured storage.

  Fix: Store secrets only in the iOS Keychain or the Android Keystore-backed storage, keep as little data on the device as possible and clear it on logout.

• MediumMobile

  No certificate pinning

  The app trusts any certificate signed by a CA in the device trust store. An attacker who can add a CA (a corporate proxy, a malicious profile, a compromised device) or who obtains a mis-issued certificate can read and change the app's HTTPS traffic.

  Fix: Pin the public key of your API's certificate (or its issuing CA) with at least one backup pin and a rotation plan, using the platform's network security configuration where possible.