1. Scope
This policy covers the applications AppExpertly publishes to third-party marketplaces, the infrastructure that runs them, and the credentials they hold on a customer's behalf. It applies to everyone who can deploy to or access production.
Figures that vary by application — retention windows, which permissions an application requests — live in that application's own privacy policy. Where the two differ, the application's is the specific one and governs.
2. Principles
Customer credentials are the asset worth protecting. Our applications hold OAuth tokens that can act inside a customer's account on another platform. Losing one is worse than losing our own infrastructure, because the customer cannot tell it happened and cannot undo what was done with it.
Least data. Applications store identifiers that point back into the customer's own systems rather than copies of those systems. What we do not hold cannot be lost.
Refuse before acting. Authorisation is checked before a third-party API is called, never after. An action that fails a check has no external effect.
3. Credentials and encryption
- At rest — third-party refresh tokens, and any value that grants privileged access, are encrypted with AES-256-GCM before storage. The key is supplied by environment rather than held in the database, so a database copy alone yields no usable credential. Key rotation is scripted and runs without downtime.
- In transit — TLS on every external connection. Database connections require it and are refused without it.
- Access tokens are never persisted. They live for the duration of a request and are refreshed from the encrypted refresh token as needed.
- Shared secrets rotate without an outage. Inbound secrets accept a previous value alongside the current one during changeover, so the environment and the third-party dashboard need not change in the same instant. Rotation completes when the previous value is unset.
4. Authenticating inbound traffic
Every inbound integration endpoint is authenticated. Where a platform offers no authentication of its own, a shared secret travels in a request header, never in a URL, because URLs pass through dashboards, logs and support tickets.
Webhooks from platforms that sign their requests are verified by HMAC-SHA256 over the raw request body before that body is parsed or stored. Unsigned and mis-signed requests are rejected. Events are recorded and deduplicated on a natural key, so a redelivery cannot apply an effect twice.
5. Tenancy isolation
An application serving many customers checks, on every operation, that the record it is about to act on belongs to the customer asking. This is enforced in both directions: outbound actions refuse before calling the third party, and inbound events for records we did not create are discarded rather than delivered.
We treat this as a correctness requirement rather than a hardening measure. A missing check is a defect, not a weakness to be scheduled.
6. Network exposure
One inbound port per application, terminated at a reverse proxy. Background workers listen on nothing. Caches and queues are reachable only on an internal network. Databases accept connections only from an allowlisted network, never from the open internet.
7. Deployment and access
Deployments run from continuous integration, never from a developer's machine. Cloud credentials are issued per run and expire with it; no long-lived cloud access keys exist. Images are tagged by the commit that produced them, and a rollback to a previous image is a first-class operation rather than an improvisation.
Production access is limited to the people who need it for their work, and credentials are not shared between them.
8. Development practice
Every change is typechecked, built and tested in continuous integration before it can merge, and again before it deploys. A failing check blocks the deployment rather than warning and proceeding.
Security review is performed against the codebase and recorded, with findings carried as numbered items each with a severity, the access an attacker would need first, and a dated resolution. Open findings stay listed rather than being closed by age. See the Vulnerability Management Policy.
9. Data handling
See the Data Retention and Protection Policy. In summary: personal data an application carries ages out automatically, a purge on request removes every record held for one customer, and no application stores payment card details or a password for any third-party account.
10. Reporting a vulnerability
Report to dev@appexpertly.com. Tell us what you did, what happened, and what you expected. We acknowledge within two business days.
We will not pursue anyone who reports a genuine finding in good faith and gives us reasonable time to fix it. Please do not access data belonging to anyone other than yourself while testing.
11. What we do not claim
AppExpertly holds no SOC 2 and no ISO 27001 certification, and no third-party penetration test has been performed. Automated scanning in continuous integration is in progress rather than in place.
These are stated here rather than left to be discovered. A document that overstates one control is a reason to doubt the others.
12. The other documents
- Vulnerability Management — where findings come from, how they are rated, and how quickly they are fixed.
- Incident Management and Response — how we learn of an incident, who responds, and when you hear from us.
- Data Retention and Protection — what is kept, for how long, and how it is deleted.
- Infrastructure and Dependency Management — how our applications are built, deployed and rolled back.
- Privacy Policy and Terms of Service for the marketplace itself. Each application also publishes its own.