This page answers the security questions customers ask. Each statement below matches how the service is built and run. For how we handle personal data, read the privacy notice.
Hosting
The service runs on Amazon Web Services in the eu-west-2 (London) region. Customer data is stored in that region.
The site is served through Amazon CloudFront, with a web application firewall (AWS WAF) in front of it. The firewall limits each IP address to 2,000 requests in 5 minutes.
Encryption in transit
- CloudFront redirects every HTTP request to HTTPS.
-
Every response carries
Strict-Transport-Securitywith a maximum age of 365 days that includes subdomains. A browser that has visited once keeps using HTTPS. -
Responses also carry a Content Security Policy,
X-Frame-Options: DENY,X-Content-Type-Options,Referrer-PolicyandPermissions-Policyheaders.
Encryption and recovery at rest
- Customer records are in Amazon DynamoDB tables. DynamoDB encrypts its tables at rest.
- Point-in-time recovery is on for the DynamoDB tables.
- Scheduled backups keep daily copies for 35 days, weekly copies for 90 days and monthly copies for 365 days. A second AWS account holds a copy of the backups in a vault with its own encryption key.
- Receipts for submissions to HMRC are kept for seven years. HMRC requires you to keep tax records for that time. Other retention periods are in the privacy notice.
- The database stores a hashed form of your user identifier (HMAC-SHA256 with a secret salt), not the identifier itself.
Sign-in
- Sign-in uses Amazon Cognito, with sign-in through your Google account.
- The sign-in flow uses an authorisation code with PKCE (code challenge method S256). The token endpoint of the service rejects a request that has no code verifier.
-
Your browser keeps the Cognito tokens in local storage. The service has no cookie session. The API reads a bearer
Authorizationheader and reads no cookies, so another website cannot make your browser send a credential to it. - The Content Security Policy limits the origins that can run script on the pages.
HMRC access and credentials
- You connect to HMRC through HMRC's own OAuth 2.0 consent page. We never see or store your Government Gateway password.
- In the browser, the HMRC access token is kept in session storage, which the browser clears when you close the tab. The browser sends it to the service as a bearer token for each HMRC call.
- When an AI assistant connects to the service through the MCP interface, the service keeps the HMRC tokens for that grant sealed with AES-256-GCM in a DynamoDB item that expires after 24 hours.
- The secrets that identify the service to HMRC are in AWS Secrets Manager. They are not in the source code.
Security testing
Automated checks run on a schedule and on code changes.
| Check | What it covers | When it runs |
|---|---|---|
| OWASP ZAP | Attacks the running site and reports weaknesses | Weekly compliance run |
| CodeQL | Static analysis of the JavaScript source | Every push and pull request, and on a schedule |
| ESLint security rules | Static analysis for unsafe code patterns | Weekly compliance run |
| npm audit | Known vulnerabilities in dependencies | Weekly compliance run |
| retire.js | Known vulnerabilities in browser libraries | Weekly compliance run |
| Dependabot | Update proposals for GitHub Actions, npm and Maven dependencies | On a schedule |
| Pa11y, axe-core and Lighthouse | Accessibility and page quality, described in the accessibility statement | Weekly compliance run |
Report a vulnerability or an incident
Contact us through the details in our security.txt file, or write to admin@diyaccounting.co.uk. The privacy notice says how we tell you and the regulator about a breach.