Performance & Security
Core Web Vitals, hardening, and the engineering behind both.
Performance & Security
Security audits, ranked by severity.
A security audit finds the weak spots an attacker could use, before an attacker does. You get every finding with evidence, ranked, plus a fix plan in order.
What is a website security audit?
A website security audit is a structured review of how a site or web app could be attacked. It covers settings, logins and access, form inputs, APIs, add-on packages and backups. ASquared Creatives rates each finding by severity and delivers a fix plan in priority order. It is not a penetration test or a certification.
01/WHAT YOU GET
What you get.
- An agreed scope of what gets tested
- A findings report with evidence and severity
- A review of packages, plugins and advisories
- A review of settings and security headers
- A fix plan in priority order
- A retest of the findings you fix
A good fit for
- Sites with no security review since launch
- Teams handling accounts, payments or personal data
- Companies inheriting code from another supplier or developer
02/HOW IT WORKS
How the work runs.
Scope
We agree what is tested, with what access and when, so live customers are not affected unexpectedly.
Inventory
We map what is exposed: domains, pages, APIs, admin areas, packages and platform versions.
Review
Tools find known issues first; then we review each layer by hand for what tools miss.
Rate and report
We confirm each finding, record the evidence, rate its severity and remove false alarms.
Plan remediation
We order findings by severity, exposure and effort, and explain the reason for each priority.
Retest
We test fixes again and update the report: closed, still open, or accepted with a reason.
03/PROBLEMS
What we fix.
Problem
Old plugins and packages nobody checks
What we do
We check every package and plugin against its published security advisories.
Problem
One account can reach data of another
What we do
We review access for each user role by hand, because scanners miss these problems.
Problem
Settings left at their defaults
What we do
We review security headers, error messages, HTTPS setup and exposed admin paths.
04/COMPARISON
Scanner, audit or penetration test?
| Assessment | What it does | Offered here |
|---|---|---|
| Automated scan | Finds known issues fast, but misses business logic. | Yes, as one part of an audit only. |
| Security audit | Reviews settings, access, inputs, APIs and packages, then ranks findings. | Yes. This is the service on this page. |
| Penetration test | Tries to exploit weaknesses to prove an attacker could. | No. Commission a specialist firm where one is required. |
| Certification audit | Independent assessment against ISO 27001, SOC 2 or PCI DSS. | No. We do not certify, attest or assess compliance. |
05/QUESTIONS
Frequently asked questions
Will a security audit disrupt our live website?
It should not. Testing runs against a staging environment where one exists, automated tools are rate-limited, and anything that could affect production, such as testing a login or a form, is agreed in writing with a time window first. Nothing is tested against live customer data without explicit agreement.
What access do you need for a security audit?
It depends on the scope. A review of what is publicly exposed needs no access at all, while a review of access control, configuration and dependencies needs test accounts for each role, read access to the code or platform settings, and ideally a staging environment. Credentials are used only for the agreed scope and revoked afterwards.
What happens after the audit report is delivered?
The report comes with a remediation plan in priority order. Your team can work through it, or we can implement the fixes as a separate piece of work. Once fixes are in place, the affected findings are retested and the report is updated to show what was closed, what remains and what was accepted with a stated reason.
Is a security audit legal or compliance advice?
No. An audit is a technical review, and its findings describe technical weaknesses and how to fix them. It does not assess whether a business meets a law, a contract or a standard, and it is not a certification. Questions of legal obligation belong with a qualified legal or compliance adviser.
How long does a security audit take?
It depends on the scope. A static marketing site with a handful of dependencies is a far smaller review than an application with accounts, roles, APIs and payments. The duration is agreed with the scope before work starts, and critical findings are reported as soon as they are confirmed rather than held back for the final report.
06/THE FULL DETAIL
The full detail.
Short answers are above. Open a panel below for the specifics: how we decide, what is included and the deeper questions.
Is this the right choice?
Choose a security audit when nobody can say what is exposed.
If the system has had no review since launch, or the people who built it have gone, an audit establishes the facts before anything is changed.
Choose application development when access control needs rebuilding.
Some findings are not configuration changes. When authorization has to be redesigned, the work moves to web application development, with the audit as its brief.
Choose a specialist penetration test when exploitability must be proven.
When a contract, insurer or regulator requires evidence that vulnerabilities can or cannot be exploited, commission a penetration test from a firm that provides one.
Which parts of a site does a security audit examine?
A security audit examines every layer an attacker can reach: transport and certificates, security headers, error handling, inputs and APIs, authentication, sessions and access control, stored data and backups, and the dependencies and platform versions underneath. The scope agreed at the start decides which layers apply, since a static site exposes far less than an application.
Broken access control, security misconfiguration, software supply chain failures, injection and authentication failures are among the most critical security risks to web applications. An audit uses those risk categories to decide where to look closely, but they are not a checklist that proves a site is safe once every item is ticked.
Will an audit find every vulnerability?
No. An audit reviews an agreed scope at a point in time, with the access it was given. Unknown vulnerabilities, systems outside the scope and changes made after the audit are not covered, which is why the report states its scope and date, and why reviews are repeated after significant changes.
How are security audit findings ranked?
Findings are ranked by severity first, usually with the Common Vulnerability Scoring System, which rates severity from Low at 0.1 to Critical at 10.0. Severity is then weighed against exposure, the data involved and the effort to fix, because remediation decisions also depend on factors a CVSS score does not include.
The score ranges below are the CVSS severity bands. The timing attached to each band is how ASquared Creatives schedules remediation, not part of the standard, and it moves with exposure.
- Critical, 9.0 to 10.0: reported immediately, before the full report is complete.
- High, 7.0 to 8.9: fixed in the current cycle of work.
- Medium, 4.0 to 6.9: scheduled, and brought forward where exposure is high.
- Low, 0.1 to 3.9: fixed when convenient, or accepted with a stated reason.
What is a dependency and supply-chain review?
A dependency and supply-chain review checks the third-party packages, plugins and frameworks a site is built on against published vulnerability advisories, then looks at how those components are chosen, pinned and updated. A site inherits every weakness in the components it includes, which is why software supply chain failures are among the most critical web application risks.
Tools such as npm audit report known vulnerabilities in installed packages, and some of them need manual review rather than an automatic upgrade. The review reads those results in context: whether the vulnerable code is actually reachable, whether a patched version exists, and what upgrading would break.
It also covers the process around dependencies: lockfiles committed to the repository, abandoned or unmaintained packages, plugins installed and forgotten, and whether anyone is told when a new advisory affects the site.
Which security headers should a website send?
Recommended security headers include a Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options set to nosniff, a Referrer-Policy and frame protection against clickjacking. Each header addresses a specific class of attack or data leak, and each has to be configured for the scripts, embeds and third parties the site really uses, or it breaks them.
A Content-Security-Policy is mainly a defense against cross-site scripting, and setting one is not an alternative to sanitizing input. The frame-ancestors directive protects against clickjacking. Strict-Transport-Security tells browsers to use HTTPS only, and browsers ignore it on a plain HTTP response, so it takes effect only once HTTPS is working.
Can security headers be added without breaking anything?
Yes, when they are introduced carefully. A strict Content-Security-Policy can block analytics, payment forms, embedded video and chat widgets, so the policy is built from the resources the site actually loads, tested for violations, and widened deliberately whenever a new third party is added.
Everything included
- Security audits
- Vulnerability assessment
- Dependency and supply-chain review
- Configuration review
- Prioritized remediation plan
What a security audit examines.
A website is attacked in layers, and an audit reviews each one, because a strong layer does not make up for a weak one beside it. Which layers apply depends on what the site actually runs.
Transport and edge
HTTPS configuration, HSTS, certificates, redirects, and anything exposed at the domain, CDN or firewall.
Security headers and errors
Content-Security-Policy, frame protection, content-type handling, referrer policy, and error pages that reveal too much.
Inputs and APIs
Validation and output encoding on forms, parameters and API payloads, plus API authentication, authorization and rate limits.
Authentication and access
Sign-in, session and token handling, two-factor options, and server-side permission checks on every request.
Data and backups
How sensitive data is stored and exposed, who can reach the database, and whether backups have ever been restored.
Dependencies and platform
Packages, plugins, frameworks and server software checked against published advisories and supported versions.
Why it matters
Exposure you can see
A findings report replaces assumptions with evidence, so decisions about security spending start from what is actually exposed.
Effort in the right order
Severity ratings and a plan mean the most serious weaknesses are fixed first, instead of whatever a scanner happened to list at the top.
Fewer surprises from dependencies
Known vulnerabilities in packages and plugins are found by your team before someone outside it finds them.
A baseline to compare against
The next audit, release review or incident has a documented starting point, so change can be tracked rather than guessed.
Where it applies
An application inherited from another team
Nobody left can explain how access control works. The audit documents what exists, what is exposed and what must change first.
A store before its busiest season
Dependencies, admin access and configuration are reviewed before traffic peaks, when a compromise would cost the most.
A site cleaned up after a compromise
The damage has been removed, but not necessarily the way in. The audit looks for the entry point and the weaknesses that remain.
Technology and approach
- Findings are rated with CVSS or an equivalent published scale, and the report states that severity is not business risk, which also depends on context CVSS does not include.
- Recognized web application risk categories and testing methods inform what is reviewed and how.
- Automated scanning and dependency audits such as npm audit find known issues; manual review covers access control, business logic and configuration that tools do not understand.
- Testing runs against staging where one exists, and never against production data without written agreement on scope and timing.
- Access and credentials provided for the audit are used only within the agreed scope, and are revoked or rotated when the work ends.
- Penetration testing, compliance certification and attestation such as SOC 2, ISO 27001 or PCI DSS are not provided, and nothing in a report is legal advice.
07/RELATED
Related services
Talk to us about Security Audits & Vulnerability Assessment.
Tell us what you need and when you need it. We reply with a clear scope and the next steps.