Internal applications are often assumed to be safe because "only employees use them". In practice, most incidents start on the inside: one leaked password, one guessable URL, one attachment downloaded without a permission check. Here are ten things to check before an enterprise application goes to production.

1. Deny by default on the server

Every endpoint must require an explicit permission. A new endpoint that forgot its permission attribute must be blocked, not open to all. Verify by calling every endpoint with an account that has no rights and confirming they are all refused.

2. Check permission per record

Blocking by screen is not enough. For every request carrying a record identifier, the server must check whether the caller may see that specific record. This is the most common hole in enterprise applications: change one number in the URL and you are reading another department's file.

3. Sessions and tokens

• Short lifetime for access tokens with a refresh mechanism; revocable when someone leaves.
• Logout must invalidate on the server, not only clear the browser.
• Limit failed logins per account and per network address to stop password guessing.
• Enable two-factor authentication for high-privilege accounts.

4. Input handling

Validate on the server, always — browser-side validation is for user experience and has no security value. For database access, use parameters instead of string concatenation. For user-entered content that will be rendered back on a page, sanitise using an allow-list of tags, never a block-list.

5. Uploaded files

• Detect the format from the file's leading bytes; do not trust the extension.
• Limit size and count.
• Store outside the web directory, named by a generated identifier rather than the name the user supplied.
• On download, check permissions like any other data; the file path must not be guessable.

6. Configuration secrets

Connection strings, signing keys and service passwords do not belong in source code or in configuration files pushed to the repository. Use environment variables or a secret store, and rotate keys periodically. One accidental push of a key to a public repository is enough to require rotating everything.

7. Log at the right level

Logs must be enough to reconstruct what happened, without becoming a place where data leaks.

• Record: who, did what, when, on which record, succeeded or was refused.
• Do not record: passwords, tokens, card numbers, sensitive content.
• Log permission refusals in particular — an unusual run of refusals is an early sign of an incident.

8. Error handling that reveals nothing

Error messages returned to users must be short and neutral. Stack traces, table names and queries belong in the server log only. The framework's default error page should be off in production.

9. Connections and protective headers

• Require HTTPS, redirect all traffic, enable HSTS.
• Set a content security policy to limit scripts from outside.
• Configure CORS against a specific domain list; never use a wildcard for an authenticated application.
• Rate-limit sensitive endpoints such as login, password reset and public form submissions.

10. Backups and a restore drill

A backup you have never restored is not yet a backup. At least once, rebuild the entire system from backup on a different machine and time it. That number is your company's real recovery time.

What to do regularly

• Update libraries and platform — most exploited vulnerabilities already had a patch.
• Review the account list, especially leavers and service accounts.
• Re-check administrator group membership every quarter.
• Rehearse one incident scenario: who notices, who is told, how the system gets locked down.

Security is not a task you complete once; it is a handful of small habits repeated steadily. None of the ten points above requires expensive tooling — mostly discipline while writing code and while operating the system.