System audit

The free audit checks what is visible from outside. The system audit goes behind the login with read access – for shop platforms, CMS, CRM and custom web applications. It is paid and always begins with an enquiry, never with an access.

How it proceeds

1. 1

   Enquiry

   You briefly describe which system is involved and what matters to you about it. Credentials do not belong in this form.

2. 2

   Initial talk and quotation

   We settle the scope and what is to be checked. You get a written quotation with effort and price. Only after that does it continue.

3. 3

   Set up access

   You create a dedicated account with read rights – not a shared admin password. Depending on the system also an API token, basic auth or a session cookie. The access applies only for the agreed period.

4. 4

   The audit

   The public part automated, the backend automated or manual depending on the system. Only reading takes place: nothing changed, nothing installed, nothing deleted.

5. 5

   Report and discussion

   You get the report with a release verdict, individual findings, a phase plan and a cost indication – with a walkthrough if you want one.

6. 6

   Revoke access

   When it is done you delete the account or revoke the token. That is part of the procedure, not a request on the side.

Load time: measured, not estimated

The same applies to the system audit as to the free scan: load time comes from Google PageSpeed Insights and not from a rule of thumb of our own. The report lists separately:

• The lab value. Google Lighthouse measures under standardised conditions – throttled mobile network, mid-range device, empty cache. Reproducible, and therefore the basis for comparing before and after. Included are LCP, FCP, Speed Index, Total Blocking Time and CLS, each rated individually.
• The field data. What real visitors experienced over the past 28 days, from the Chrome UX Report. That is the number Google ranks on. Each metric appears as a pie chart: how many visitors were served well, adequately or badly. A single number hides exactly that – a mediocre average can mean everyone loads mediocrely, or that most load very fast and a minority very slowly. Only the second case has a clear cause.
• The individual actions. Lighthouse quantifies the time saved in seconds and the bytes saved for each action. The report sorts by that, so the order of work is settled.

If a domain has too little traffic, Google publishes no field data. The report then says so explicitly instead of leaving a gap – it is not a bad mark but a statement about the data available.

Make an enquiry

Code analysis

From outside the source code is invisible – yet the most common serious faults sit precisely there. If the code is available (repository access or an archive), it is checked additionally against a fixed set of rules:

• Secrets in the code – keys, tokens, passwords, .env files checked in by accident
• SQL without placeholders, unescaped output, missing input sanitisation – the routes to SQL injection and XSS
• Missing permission and nonce checks before writing actions
• Tracking before consent in the template
• Development leftovers in the shipped state: debug output, test accounts, open configuration

The result is a list with file and line, plus the rule that was broken – traceable and repeatably verifiable.

What you get

• Report on the public and the signed-in part
• Findings from the code analysis with file and line, if code is available
• User accounts, roles and orphaned access
• Plugin and theme versions with their known vulnerabilities
• Pending updates with their urgency
• Configuration errors and system diagnostics
• Phase plan with effort and cost indication