Solution · Security
Website and application security audit
Most successful attacks on small and medium businesses do not require brilliant hackers. They use an outdated plugin, a password shared among five people, an admin panel open to the whole internet or a backup that was never tested. A security audit finds these weak points and ranks them, so you fix the ones that matter first.
[ 01 ]
In short
In short
- 01
An audit answers three questions: how could someone get in, what could they reach, and how fast could you recover.
- 02
It covers people and processes — who has access, how passwords are stored — as well as code and servers.
- 03
The result is a prioritised list with concrete fixes, not a scary report with hundreds of generic warnings.
- 04
A penetration test is a separate, deeper exercise that actively tries to break in; an audit is the usual first step.
- 05
Security is a state that decays; the audit is a starting point for monitoring and regular updates.
[ 02 ]
Scope
What we check
Access and accounts
- Who has access to hosting, domain registrar, DNS, admin panels, databases, code repositories and email.
- Shared accounts and passwords, former employees and contractors with active access.
- Two-factor authentication on critical accounts.
- Where passwords and API keys are stored.
See access management for teams.
Software and updates
- Versions of the platform, plugins, libraries, server software and their known vulnerabilities.
- Unused plugins, themes and test files left on the server.
- The update process — whether updates are tested before being applied.
Configuration
- HTTPS everywhere, correct certificate setup, security headers.
- Admin areas exposed to the internet, default paths and credentials.
- File permissions, directory listing, error messages that reveal internal details.
- Database and service ports open to the world.
- Email domain protection (SPF, DKIM, DMARC). See email domain security.
Application logic
- Forms and APIs: validation on the server, protection from injection and cross-site scripting, rate limits on login and contact forms.
- Authorisation: can one user see another user's data by changing an ID in the address?
- File uploads: what can be uploaded and where it is stored.
- Payment flows: can a payment status be forged?
Data
- What personal and commercial data is stored, where, and who can access it.
- Encryption of sensitive data and backups.
- Retention: data kept longer than needed is a liability.
- Requirements of Azerbaijan's personal data law that apply to your case; see personal data law for websites.
Recovery
- Backups: what is backed up, how often, where, and when a restore was last tested.
- Logs: whether an incident could be investigated.
- Who is responsible and reachable if something happens at night.
The report
Each finding includes what it is, why it matters in your context, how to fix it and how urgent it is. We separate critical issues — to be fixed immediately — from improvements that can be planned. Where you have your own developers, the report is written so they can act on it; otherwise we fix the issues ourselves.
Audit vs penetration test
An audit reviews configuration, code and processes with full access. A penetration test simulates an attacker trying to break in, often with limited knowledge. For most businesses, an audit and fixes come first; a penetration test makes sense afterwards, for systems holding sensitive data or when a client or regulator requires it.
After the audit
Closing today's issues does not protect against tomorrow's vulnerabilities. We recommend regular updates, 24/7 monitoring, tested backups and an incident playbook. The pre-launch version of this checklist is in security checklist before launch.
What we need from you
- Access to servers, hosting panels, admin panels and code, or an agreed read-only access.
- A list of systems and who is responsible for each.
- Any past incidents and your lawyer's requirements for data storage.
[ 03 ]
FAQ
Frequently asked questions
Will the audit disrupt our website?
No. The audit is a review, not an attack. Any active checks are agreed in advance and run carefully, outside peak hours if needed.
We use a website builder. Do we need an audit?
The platform handles server security, but accounts, access, integrations, forms and data handling are still your responsibility. A lighter audit focused on those is useful.
How often should an audit be repeated?
After major changes, and at least yearly for systems holding customer data. Continuous monitoring covers the time between audits.