Information security audit of a web resource

Executive summary

This section avoids technical terms. It is written for the reader who decides on budget and deadlines, not for the one who does the work.

Purpose

An independent assessment of how well the web resource and its infrastructure are protected against unauthorised access, leaks of user data, loss of availability and bypassing of business logic.

Overall assessment

The level of protection is assessed as satisfactory. No vulnerability allowing immediate control of the server or extraction of the database was found. At the same time there are weaknesses in authentication, security headers and session cookie attributes which are not critical on their own but together widen the attack surface noticeably.

What to do first

1. Rate-limit login and password reset. One setting that closes the only high-severity finding.
2. Fix the session cookie attributes and stop disclosing software versions in responses. Half a day of work.
3. Roll out a Content-Security-Policy. It needs testing, so it is a separate stage.

Scope and methodology

What was tested

• The client domains and subdomains on the agreed list
• Public API endpoints
• Registration, login, password reset and session handling
• Upload and delivery of user files
• Web server configuration and response headers

What was not tested

• Third-party services: CDN and payment gateway. Only the correctness of the integration was checked
• Volumetric denial-of-service attacks
• Social engineering against the client’s staff
• Physical security and the internal office network

The scope was fixed before the work started and did not change. Anything outside it was not tested, and the absence of findings there does not mean it is secure.

Rules of engagement

The work followed rules agreed in writing as an annex to the contract: the list of permitted domains and addresses, the testing window, a contact for an emergency stop, and a ban on modifying or deleting data. Anything that could disrupt the service was performed only after written approval.

Depth of testing

The scope of work is agreed in advance and comes at two levels. Testing without exploitation: a vulnerability is recorded from its indicators, without carrying the attack through, which is safe for a production environment. Controlled exploitation: a vulnerability is taken to a confirmed result, so that a theoretical risk can be told apart from a real one and it is clear what data an attacker would actually reach. The second level is performed only under separate written permission, in an agreed window, with the ability to stop immediately.

The public version of the report does not list the methods, tools and attack chains used. The working report states them in full: the client must know what was tested and how to reproduce the result.

Standards

• OWASP Web Security Testing Guide 4.2
• OWASP Top 10:2021
• NIST SP 800-115
• Severity scored with CVSS 3.1

Handling client data

No user data was extracted. Logs and configurations supplied for analysis were processed inside our closed environment. Where language models were used to work through large volumes, the model was deployed locally with no internet access: the contents of logs and configurations never reached external services. The conclusions and wording were checked by an engineer by hand.

Detailed findings

Every finding follows the same shape: what exactly is wrong, what it threatens for the business, how it was confirmed and what has to be done. The identifier is used in correspondence and during the re-test.

Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
Permissions-Policy: camera=(), microphone=(), geolocation=()

Set-Cookie: session_id=...; Secure; HttpOnly; SameSite=Lax; Path=/

# nginx
server_tokens off;

# application — remove the X-Powered-By header

The sample holds four findings out of ten, and each is cut down. In the working report a finding carries reproduction steps, full requests and responses, screenshots, references to the affected code and configuration and — where exploitation was permitted — a confirmed scenario describing what was actually reached. That is everything a developer needs to fix the issue and check their own work. Publishing such text about someone else’s live system is not acceptable.

Remediation plan

The order follows the ratio of risk removed to effort spent: the work that removes the most risk for the least effort comes first.

On request the findings are exported to the client’s tracker as individual tasks, with descriptions, references to affected files and acceptance criteria.

Re-test and limitations

Re-test

Once the fixes are in, we re-test the findings that were reported closed. The result is an annex to the report where every finding gets a status: fixed, partially fixed or still open. The period during which the re-test is included in the price is set in the contract.

Limitations

• The assessment reflects the state of the system on the date of testing. Any change to code or configuration after that date can introduce new vulnerabilities.
• The absence of a finding does not prove the absence of a vulnerability. An audit is bounded by its agreed scope, its time and the methods available.
• Absolute security does not exist. The aim is to bring risk down to an acceptable level and make it manageable.

Reference material

How to read the severity

Logs and investigation

If the audit raises a suspicion that a breach has already happened, how far an investigation can go is decided entirely by what survived in the logs. The minimum worth keeping, and worth keeping off the server itself:

• Web server access and error logs
• Operating system and application authentication logs
• Logs of permission changes and account creation or deletion
• Deployment logs: who changed code and configuration, and when
• The server’s network connections, at least in aggregate

If you suspect a breach, do not reinstall the system and do not delete files. That destroys the traces and makes it impossible to reconstruct what happened. The right first step is to take an image, or at least a copy of the logs, and only then restore service.

Terms

• Grey Box — testing with partial knowledge of the system: an account and a general description, but no source code.
• CVSS — an international scale for scoring vulnerability severity from 0 to 10, with an open methodology.
• OWASP Top 10 — a list of the ten most common classes of web application vulnerability.
• Rules of Engagement — rules agreed before the work: what may be tested, when and by which methods.
• Attack surface — the set of points through which a system can be acted upon.