Quick answer
If deployment may have exposed a password, token or private key, contain access promptly and preserve minimal redacted evidence. Remove the public copy, rotate the affected credential with its owner and verify the application. Deleting a file cannot invalidate a secret already copied.
Treat a served secret as an incident
A migration can place environment files, dumps or archives in the served directory. Identify the effective document root and file owner; the usual DirectAdmin public_html path can be overridden. Filename or location alone does not establish public exposure.
Use only an account and hostname you are authorised to inspect. Do not browse for other customers’ files or paste a secret into a ticket to prove the problem.
Inspect deployment output without copying secret values
Compare the deployed file list with the intended public build. Look for unexpected environment files, configuration copies, database dumps, archives, private keys and old release folders near the served root. Record filenames, paths, owner and deployment time; do not include file contents in a general inventory. Check whether the build pipeline copied a whole project directory instead of only deployable assets.
Record minimal redacted evidence and contain the suspected exposure promptly. Use the file manager or approved deployment access to move sensitive material outside the served tree when you own it; do not delay containment merely to prove that a secret is downloadable. If the location is controlled by the operator or application framework, ask the responsible party to make the change safely.
Verify public accessibility through the real hostname
Check only the specific suspected path through the real HTTPS hostname, using an unauthenticated header request or operator-led evidence. Record status and content type, but do not fetch or save a live secret body to prove exposure. Where a controlled non-sensitive marker or safe redacted operator comparison is already available, use it; otherwise treat possible credential exposure as an incident and contain and rotate it with the owner. A 200 status on a login page is not proof that the requested file was served. A 403 or 404 response reduces immediate exposure evidence but should be checked against the actual host variants and cache layer. Stop testing if the response contains a live secret and preserve only minimal redacted evidence.
Do not publish an example URL containing an actual secret or invite search engines to index the path. Confirm removal or denial with a fresh unauthenticated request after remediation.
Example: an environment file entered the public build
If the deployment inventory contains an unexpected environment file under the effective web root, record its path and deployment time without copying its values. Remove or restrict it promptly through the authorised route. If it may have been served, rotate its credentials even when a later request returns 404.
Do not retrieve a live secret just to demonstrate exposure after containment. Record the known path, time and safe response evidence; ask the operator to assess relevant host variants, logs and cache copies without distributing the secret.
Remove exposure and rotate affected credentials
Contact the application owner and Novasean support promptly. Remove the file from public deployment and correct the packaging or document-root mistake. Treat any credential that may have been fetched as exposed: identify its service owner, revoke or rotate it through that provider’s approved process, update the application securely, and verify normal operation with the new credential. Rotation order matters for availability; coordinate database, API and webhook keys with their owners. If a provider-owned key is involved, escalate rather than attempting to change it from a customer account.
Review available access logs and cache/CDN behaviour with the operator to understand the exposure window. Deleting the file alone does not invalidate a key that was copied. This guide does not recommend rewriting Git history; that is a separate repository problem.
Frequently asked questions
Is an environment file safe because its name starts with a dot? Do not rely on naming. Confirm the actual web response and keep secrets outside the served directory.
Is a 404 enough to close the incident? It is one check. Confirm every relevant hostname and cache path, then rotate a credential if exposure cannot be ruled out.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.