Security

This page summarizes how Auctollo protects the data in your account, as the app works today. It is an overview, not a contract: the Terms of Service, the Privacy Policy and the Data Processing Agreement (DPA) govern, and where this page differs from them, they apply.

1. Encryption in transit

app.auctollo.com is served over HTTPS. Every response tells the browser to keep using HTTPS (a Strict-Transport-Security header with a two-year lifetime that includes subdomains), and the page's content security policy tells the browser to upgrade any insecure request it would make.

Our DPA commits that customer personal data is transmitted over TLS 1.2 or higher (DPA section 8).

2. Encryption at rest

The secrets we must be able to read back, to sign for your site or call a service you connect, are stored only as AES-256-GCM ciphertext: the key that signs messages from your WordPress site, the Google Search Console and Bing credentials you connect, the Google Analytics credential you connect, the API key for a log source you connect, the secret that signs the requests we send to a webhook you set up, and the Google credential the plugin uses for “Connect with Google (via Auctollo)”. The encryption key is kept in our hosting provider's configuration, separate from the database, so a copy of the database alone does not reveal them. Each value is also bound to the record it belongs to, so a ciphertext copied into another account's record fails to decrypt. If the key is not configured the app refuses to store the secret; it never falls back to plain text.

Our DPA also records that encryption at rest for our primary data stores is managed by our infrastructure sub-processors (DPA section 8).

3. API keys, tokens and other credentials

API keys, OAuth authorization codes and tokens, team-invite links, the credential the plugin uses to connect with Google through us, and the credential a Cloudflare log push presents are stored only as one-way hashes of their values, so reading the database does not give anyone a working credential. We show you an API key once, when you create it; we cannot show it again.

4. Row-level security

Every table our application creates has row-level security turned on. That makes the database itself, and not only our application code, decide which rows a signed-in user may read or change: an account sees its own sites and data, and a team member sees the sites of the account they belong to, and nobody else's. The tables that hold the encrypted secrets above have no user-facing access at all; only our servers read them. Our servers also use a privileged database role for work that has no signed-in user, such as webhooks and scheduled jobs, and that role is not subject to these policies.

5. Protection against server-side request forgery

Our servers fetch pages, sitemaps and robots.txt from the sites you connect, send the browser notifications you turn on, send a wake-up request to your site's WordPress cron, and deliver the webhook events you set up to the address you give us. A hostile address could try to turn requests like these into requests to our own internal systems, so each of them goes through one guard that:

• allows only web addresses, on the ports 80, 443, 8080 and 8443;
• resolves the host name itself and refuses the request if any address it resolves to is not on the public internet (loopback, private, link-local, cloud-metadata, shared-address and reserved ranges);
• connects only to the addresses it checked, so a DNS answer that changes between the check and the connection cannot redirect it;
• checks every redirect again, follows at most five, never moves from https to http, and drops credentials when a redirect leaves the original site;
• limits how much it reads from a response and how long it waits.

A webhook delivery is stricter than that in two ways: it is sent over https only, and it never follows a redirect (a redirect is read as the endpoint's answer).

6. Staff access to your account

Authorized Auctollo staff can open a read-only “view as customer” session to see your dashboard as you see it, so we can resolve support requests. A session cannot change your settings, sites or other account data, ends automatically after 30 minutes, and is recorded in an internal staff audit log together with the dashboard pages viewed. Your Google Search Console data is hidden from these sessions. Authorized staff can also make administrative changes to an account, such as issuing credits or a refund; those are recorded in the same audit trail. Sections 6 and 7 of the Privacy Policy describe this in full, including how long the records are kept.

7. Data retention

Section 7 of the Privacy Policy sets out our retention periods and governs. In summary:

• Server-log lines you send us for crawl analysis: the period you choose on Privacy & data in your dashboard, 30, 90, 180 or 365 days (90 by default); a nightly job deletes older lines.
• Report files: 90 days.
• Billing evidence kept to defend payment disputes: up to 180 days after your last charge or checkout, even if you delete your account. If you were never charged, it is kept while your account is open and for up to 180 days after you delete it. A record tied to an open dispute is kept until the dispute is resolved.
• Staff audit records (the sessions and administrative changes in section 6): kept as an accountability trail and not deleted on a schedule.

8. Sub-processors

The vendors that handle customer data on our behalf, with what each does and where it processes data, are listed in section 7 of the DPA and in section 3 of the Privacy Policy. Section 7.4 of the DPA says how we notify customers when that list changes.

9. Reporting a vulnerability

Please report a security issue privately, not in a public issue or a forum post, so we can fix it before details circulate. Email security@auctollo.com (a PGP key is available on request). For the WordPress plugin you can also use the Patchstack disclosure form, naming the plugin slug google-sitemap-generator.

You can expect an acknowledgement within 2 working days and a status update within 14 days. We follow a 90-day disclosure window: from the day your report is acknowledged we have 90 days to ship a fix before details are made public. Critical issues ship faster, and we agree the timeline with you privately.

10. If something goes wrong

If a personal data breach affects data we process for you, we notify you as section 12 of the DPA (“Personal Data Breach Notification”) provides. Section 11 of the Privacy Policy covers account holders. This page adds no separate commitments.