Learn · CERT-In & Safe-to-Host

Why Applications Fail a Safe-to-Host Audit

A safe-to-host certificate is withheld, not awarded. The auditor tests the application, writes up what they found, and issues only once the findings that contradict the statement on the certificate are closed. This page is the catalogue of what those findings usually are.

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.

Talk to a Security Testing Advisor CERT-In Audits VAPT and Security Testing

9finding families this page catalogues

4of them found by looking, not by attacking

A01OWASP category with the most occurrences in the 2021 dataset

Plain-English explainer · Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · Empanelment Terms & Conditions v7.2 (April 2024) · CERT-In Directions of 28 April 2022 · GIGW 3.0 · Sources last checked 22 September 2026

Applications fail a safe-to-host audit for a narrow and very repetitive set of reasons, and nine finding families account for most of them. Those nine are broken access control and insecure direct object references, authentication and session defects, injection, unrestricted file upload, weak transport and header configuration, an administrative interface reachable from the internet, verbose errors and information disclosure, known-vulnerable components, and secrets embedded in client-side code. Broken access control — changing an identifier and receiving somebody else’s record — is the class most often found open in the CERT-In audits we deliver with our CERT-In empanelled partners, and the one automated tooling structurally cannot find. On the public dataset OWASP records the same category, A01 in the Top 10:2021, with 318,487 occurrences, the most of any entry in that edition, and states that 94 per cent of the applications in its contributed dataset were tested for some form of broken access control — a measure of how widely it was looked for, not of how often it was there. None of this is exotic. The second reason is procedural rather than technical, and it costs more calendar time than the first: the environment offered for testing was not the environment that will be hosted, the scope was drawn smaller than the deployed service, test accounts never arrived, or a release shipped mid-engagement. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, 25 July 2025) — binding, in their own words, on all CERT-In empanelled auditing organizations and auditee entities covered under the relevant provisions — are direct about the first of these: the auditor tests on the staging or testing environment provided by the hosting service provider before issuing the audit certificate (§15.2.3(ii)), the environment tested must be named (§15.2.3(i)), and where the scope was limited to staging the report must say the audit was not conducted on production (§16.3(v)).

The third reason, and the one this page spends most of its length on, is that the finding was closed in a way that does not survive a retest. A rule added to the edge filter, an identifier changed to a UUID, an extension blocklist, a key obfuscated rather than rotated: each makes the reported proof-of-concept stop working while leaving the defect in place. For the surrounding process, see how to get a safe-to-host certificate. For what the certificate is and is not, see the safe-to-host certificate explained.

Key Takeaways

Broken access control is the class most often found open in the CERT-In audits we deliver with our CERT-In empanelled partners, and the one automated tooling structurally cannot find — it needs two accounts per role, a proxy and a role-versus-endpoint matrix. OWASP records A01:2021 with 318,487 occurrences, the most of any category in that edition’s contributed dataset.
A blocking finding is one which, left open, would contradict the statement the certificate makes about the tested build in the environment the report names. Critical and exploitable high findings are not negotiable. Lower-severity findings are carried with owners and dated closure plans, because §16.3(iii) of the 2025 audit policy guidelines requires the report to state closure timelines by severity.
The scoring method is published, even though the issue-or-withhold tariff is not. §16.2(ii) requires observations to be categorised using CVSS, supplemented by EPSS for real-world exploitation likelihood, and every observation to be mapped to a CWE and a CVE. §16.3(v) requires the final report to issue after closure and completion of the follow-up audit on the production environment.
Fixes are judged at the mechanism, not at the reported path. A WAF rule, a UUID, an extension blocklist or a hidden menu item will fail a retest.
For a disclosed credential the order matters: rotate first, then fix the code. Code changes prevent the next disclosure and do nothing about this one.
The OWASP Top 10 mapping is real for access control, injection and vulnerable components, and strained for file upload, information disclosure and embedded secrets. §8 of the 2025 guidelines goes further than that and says limited lists such as the OWASP Top 10 and SANS Top 25 should not be considered standards or references for audits — it names WSTG, ASVS and MSTG among the standards it does accept. Name the edition of each you mapped against.
Procedural failures stall more engagements than technical ones: the wrong environment, an incomplete scope, missing test accounts, absent approvals, or a release shipped mid-audit.
The 2022 Directions are inside the audit whether or not you scoped them in: §15.2.1(iv) requires their verification in every audit assignment. Clock synchronisation to NIC or NPL, a current point of contact, six-hour incident reporting and 180 days of logs all surface in the same review — with CERT-In’s own FAQ answering, at question 35, that the logs may sit outside India provided they can be produced in reasonable time.
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. A safe-to-host audit is one of them.

On this page

The short answer

The nine findings that most often block a safe-to-host certificate

Ordered by how often the family is found open as the blocking defect in the CERT-In audits we deliver with our CERT-In empanelled partners, not by CVSS and not by remediation cost. Each row is expanded in full below. The bands themselves are not an invention of report writers: §16.2(ii) of the Comprehensive Cyber Security Audit Policy Guidelines requires observations to be categorised using CVSS, supplemented by EPSS for real-world exploitation likelihood, and every observation to be mapped to a CWE and a CVE. What CERT-In does not publish is a band-by-band tariff saying which severity withholds a certificate — so the “blocks issue” column is observed practice, read against §16.3(v), which requires the final report to issue after closure and completion of the follow-up audit on production.

#	Finding family	What it looks like	Typical band	Blocks issue?	Who owns the fix
01	Access control and IDOR	Change an identifier in a URL, body or header and receive another user’s record, or reach an administrative function hidden only by the menu.	High, or Critical at scale	Yes, while an ordinary account can exploit it	Application team
02	Authentication and session handling	A secondary flow is weak: the reset token that never expires, the OTP endpoint with no throttle, the session that survives a password change.	High, Critical on bypass	Yes, where the defect is exploitable	Application team, with the identity provider owner
03	Injection	Untrusted input reaches an interpreter with its structure intact: SQL, NoSQL, OS command, LDAP, XML, a template engine, or the browser’s parser.	Critical server-side, High for stored XSS	Yes	Application team
04	File upload	Type trusted from the client, the file stored where the server will execute it, the name attacker-controlled, no size or rate limit.	Critical where execution is possible	Yes where storage or execution is unsafe	Application team, with the platform team for storage
05	Security headers and TLS	Two findings a scanner prints as one: transport and certificate validity, and the browser-facing header and cookie set.	Medium mostly, High for plaintext credentials or a session cookie without Secure and HttpOnly	Only the transport and session-cookie cases	Platform team at the terminating layer
06	Exposed administrative interfaces	A management surface reachable from the internet that was designed assuming it would not be: console, database tool, debug endpoint, CI runner.	Critical with default credentials, High otherwise	Yes, on reachability alone	Platform team
07	Verbose errors and information disclosure	Stack traces, database errors, debug pages listing environment variables, directory listings, personal data in query strings that reach logs.	Low to Medium, except the two cases opposite	Only where it discloses credentials or personal data	Application team, with the platform team for banners
08	Outdated and vulnerable components	Third-party code with known advisories: runtime, framework, libraries, server, database, base image, OS packages.	Varies by advisory and by reachability	Where the vulnerable path is reachable, or the runtime is unsupported	Application team for libraries, platform team for runtime and image
09	Secrets in client-side code and repositories	A credential that has already left the server: a bundle, a mobile binary, a source map, a static config file, or repository history.	High to Critical by what the credential opens	Yes, while the credential is live	Application team, with whoever owns the credential

What failing means

Is there a pass mark for a safe-to-host audit? No — there is a statement.

Blocking finding — working definition

A blocking finding is an observation which, left open, would contradict the statement the audit certificate makes about the tested build, in the environment named in the report.

That is a working definition rather than a quotation: CERT-In publishes the severity method but no list of which findings withhold a certificate. It is the test the rest of this page applies, and it is why the useful question about a finding is what an attacker needs to use it, rather than how bad it sounds.

People ask what score an application has to reach. That is the wrong shape for the question. The auditor is not grading. They are deciding whether they can put their name to a document saying the application is safe to host, at a stated version, in a stated environment. A finding blocks when it contradicts that sentence. Everything else goes into the report with a severity and a closure timeline.

Negotiation therefore works at the bottom of the severity range and fails at the top. A missing referrer policy does not contradict the statement, but an unauthenticated path to remote code execution does, and no compensating control is available, because it would have to be trusted more than the application itself. In between, the useful question is not how bad is this but what exactly does an attacker need to use it.

“We fixed the one the tester found.”

— the sentence that produces a second retest

Severity

Which findings block a safe-to-host certificate, by severity

Two different things get conflated here, so it is worth separating them. The scoring method is published: §16.2(ii) of the Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, 25 July 2025) requires observations to be categorised using CVSS, supplemented by EPSS for real-world exploitation likelihood, and states that every reported observation or vulnerability shall be mapped with a Common Weakness Enumeration and a Common Vulnerabilities and Exposures number. The same section requires critical and high findings to be notified to the auditee during the audit on an as-and-when-found basis (§16.3(ii)), the report to state closure timelines by severity (§16.3(iii)), and the final report to issue after closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment (§16.3(v)).

What is not published is a band-by-band tariff — a rule saying this severity withholds a certificate and that one does not. The “effect on issue” column below is therefore observed practice against the instrument above, and the auditor’s judgement governs. The bands and the CVSS ranges are the instrument’s. The consequences are what we see.

Band	Scoring basis (§16.2(ii))	What sits here	Effect on issue	What closure looks like
Critical	CVSS 9.0–10.0, weighted by EPSS where it indicates a high probability of exploitation in the wild. Mapped to a CWE, and to a CVE where a component is implicated.	Unauthenticated remote code execution, authentication bypass, injection reaching the database or the operating system, an internet-reachable management console with default credentials, a live disclosed credential.	In practice, empanelled auditors do not issue while a finding in this band is open, and no compensating-control argument is available, because the finding defeats the statement the certificate makes. §16.3(ii) also requires a critical finding to be notified as and when found, so you will hear about it before the report exists.	Fixed, then verified in the follow-up audit — which §16.3(v) puts on the production environment — and usually tested around rather than at the reported path. Expect the auditor to widen scope, because one instance implies a pattern.
High	CVSS 7.0–8.9, weighted by EPSS. A discovered breach, a known-high exploitation rate or unmonitored access is reported to the auditee immediately on discovery under §16.4, with a recommended solution.	Authenticated object-level authorisation break, stored cross-site scripting reaching an administrator, unrestricted upload without execution, session fixation, a plaintext credential path.	We have not seen a certificate issued over an open, exploitable finding in this band. It is where teams try to negotiate and where the negotiation nearly always fails, because the exploit requires only an ordinary account.	Fixed and retested. Where a fix is genuinely architectural, the realistic path is a scoped interim change that removes exploitability, not an acceptance memo.
Medium	CVSS 4.0–6.9, weighted by EPSS. A medium carrying a high exploitation probability is not a medium in practice, which is what §16.2(ii) requires EPSS for.	Reflected cross-site scripting in a low-traffic path, missing rate limiting on a non-credential endpoint, verbose error detail, weak attributes on a non-session cookie, an outdated component with no reachable path.	Individually negotiable, collectively not. A report carrying thirty mediums describes a maintenance problem, and auditors read the aggregate as well as the items.	Fixed where cheap, and where deferred, carried with a dated plan and an owner. §16.3(iii) requires the report to state closure timelines by severity, so a deferral without a date is incomplete on its face. Risk treatment is authorised by the head of the auditee organisation, and an exception on the application by the head of the organisation that owns it (§9.2).
Low and informational	CVSS below 4.0, or an observation with no score at all — configuration hygiene, a version banner, a cacheable non-sensitive response.	Missing hygiene headers, version banners, cacheable non-sensitive responses, best-practice deviations with no demonstrated impact.	Does not block. Still appears in the report, and still worth closing: the cost is a configuration line, and a long low list makes the medium list look worse.	Batch them into one configuration change at the terminating layer and close the set at once.

Will the certificate be issued with this still open?

The band table answers by category. Teams ask a combination question — one high and fourteen mediums, what happens? This is that question by scenario. Observed practice, not a published rule, and the auditor’s judgement governs. One thing the table makes plain: auditors read the aggregate as well as the item, and so do the hosting reviewers who receive the certificate.

Scenario	Issued?	What the auditor requires instead	What to do this week
A critical or high finding notified mid-audit, before any report exists	Not yet in question	Nothing about issue is decided yet. §16.3(ii) requires critical and high findings to be notified to the auditee during the audit on an as-and-when-found basis, so this call is normal rather than alarming. What it buys you is calendar time — remediation can start before the report is drafted.	That day: agree a named recipient and a channel for these notifications before testing starts, so the message does not land in a shared mailbox. Then triage it as you would a production incident and begin the fix. Do not wait for the written report to make it official.
One critical finding open	No	The fix, a retest, and usually a widened retest scope. No acceptance route at this band.	Fix it, then search the codebase for the same construction everywhere else.
One high, exploitable by an ordinary authenticated account	No	The fix and a retest. This is where negotiation is attempted and nearly always fails.	Fix at the mechanism, then attack it yourself from a fresh angle before booking the retest.
One high, exploitable only with administrator credentials already held	Sometimes	An argued position: the preconditions stated precisely, who holds those credentials, what else would already be lost, and what compensates. A facts argument — and one with a named signatory, because §9.2 puts risk treatment with the head of the auditee organisation, and an exception on the application with the head of the organisation that owns it.	Write the preconditions down and produce the access list for that privilege.
A high whose fix is architectural, with an interim control in place	Sometimes	The interim control has to be testable so it can be evidenced and retested — an enforcement point in front of the vulnerable path, the feature disabled by configuration, the interface taken off the public network. Plus a dated plan.	Ship it and declare it as interim. An undeclared one found at retest is worse than the finding.
Five mediums, each with a named owner and a date	Ordinarily yes	The report carries them with the closure timelines the guidelines expect it to state.	Close the cheap ones anyway. They cost a configuration line and make the list shorter.
Thirty mediums, no owners, no dates	Expect friction	The aggregate is read as a statement about maintenance. A deferral with no date and no owner is incomplete on its face.	Assign owners and dates to all thirty. It changes what the report says about you.
Lows and informational only	Yes	Nothing. They appear in the report and do not block.	Batch them into one configuration change at the terminating layer.
A blocking finding owned by the hosting platform, not by you	No — and not by your effort either	The platform owner’s remediation, evidenced the same way yours would be. §13.1.5 puts the web server, its operating system, the hosting software and the backend database software with the organisation that owns and operates the server, while the content owner remains responsible for getting the application itself audited. The certificate waits for them.	Get the platform owner into the engagement, and make sure the report attributes the finding to them.

What does an audit observation contain?

Teams arrive at the report expecting a list and find a record. Knowing what a well-formed observation contains lets you tell a thin report from a complete one, and it is the shape your closure register joins onto. Ten of the fields are craft. The ones citing a section are required by the 2025 audit policy guidelines, which is what makes their absence a defect in the report rather than a stylistic difference. The example values follow one finding through this page. For checking the certificate the report eventually supports, see how to verify a CERT-In audit certificate.

Field	Why the auditor carries it	Example value
Finding identifier	The key the closure register, the retest result and the next audit all join on.	STH-2026-014
Title	Names the defect, not the tool output. "IDOR" is a category, not a title.	Object-level authorisation not enforced on /api/v1/grievance/{id}
Severity, with the basis stated	A band alone invites argument. A band with its scoring basis moves the argument onto facts.	High. Authenticated, no special privilege, personal data of other citizens.
CVSS vector and score	§16.2(ii) requires observations to be categorised using CVSS. The vector is what lets you argue the band — it shows which assumption the score rests on.	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — 6.5
EPSS	The same clause requires CVSS to be supplemented by EPSS, for the probability of exploitation in the wild. It is what separates a theoretical medium from an urgent one.	EPSS 0.11 (87th percentile)
CWE	§16.2(ii): every reported observation is mapped to a Common Weakness Enumeration number. It is also what makes the finding searchable against your own history.	CWE-639: Authorization Bypass Through User-Controlled Key
CVE, where a component is implicated	Same clause. Absent on a first-party defect, mandatory where the finding is a known-vulnerable dependency.	Not applicable — first-party authorisation defect
Environment tested	§15.2.3(i) requires the environment to be specified: Test, Development, UAT, Pre-Production or Production. §16.3(v) requires a staging-limited report to say the audit was not conducted on production.	Pre-Production (staging), provided by the hosting service provider
Limitations, exemptions and inaccessible assets	§16.1(ii) requires limitations and exemptions, and §10.1(ii) requires in-scope assets that could not be reached to be named with the reason. This is the field that tells you what the certificate does not cover.	Payment gateway sandbox unavailable in window. Excluded, notified.
Report version and date of issuance	§16.1(iv): draft and final versions carry dates. Without it you cannot tell which report a closure register belongs to.	v1.0 (draft) 2 Mar 2026, v2.0 (final) 16 Apr 2026
Asset inventory current as at	§13.2.3(ii)(b): the auditee states the date to which the scope and asset inventory were updated, and that date appears in the report. It is what dates the scope.	Asset inventory as at 18 Feb 2026
Affected component or parameter	Tells the fix owner where to look and lets the retest reach the same place.	GET /api/v1/grievance/{id}, parameter id, also on /export
Preconditions for exploitation	Decides severity, and is the field thin reports omit. An account? A role? A user who clicks? Nothing?	Any authenticated citizen account. No administrative privilege.
Proof of concept	Reproducible request and response. Without it the finding cannot be retested or disputed on facts.	Request and response pair with the identifier substituted.
Impact	What an attacker gets, in the language of the service. It is what the hosting reviewer reads.	Enumeration of every grievance record: name, address, phone.
Recommendation	Names the mechanism to change. Written at the path, it produces a suppression.	Enforce the authorisation decision at the data access layer.
Status	Open, closed, or closed with residual risk — the same vocabulary everywhere.	Open
Target closure date and owner	The guidelines expect timelines according to severity. A date with no owner is not a timeline.	14 days. Owner: grievance module tech lead.

The fields a thin report drops are almost always the same three: preconditions, proof of concept, owner. Without preconditions the severity cannot be argued on facts. Without a proof of concept the finding cannot be retested. Without an owner the closure date is decoration. The empanelled-auditor guidelines require observations to be supported by objective evidence compiled with the report — the same requirement from the auditor’s side. Two further fields are worth checking for by name, because their absence is easy to miss: §16.1(ii) requires the report to state its limitations, exemptions and other constraints, and §10.1(ii) requires in-scope assets the auditor could not reach to be named with the reason and brought to CERT-In’s notice. A report with no limitations section is not a clean report. It is an incomplete one.

Anchoring

Where the OWASP mapping is real, and where it is not

Start with the clause most reports on this subject never quote. §8 of the Comprehensive Cyber Security Audit Policy Guidelines — the section headed applicable standards — says that the limited lists such as OWASP Top 10, SANS Top 25 and similar should not be considered as standards or references for audits. The standards it does name are ISO/IEC standards, CERT-In’s own Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM 3, the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard, the OWASP Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model.

That is not an argument against the Top 10. It is an argument about what the Top 10 is for. GIGW 3.0 names it, alongside ISO 27001, ASVS and CIS benchmarks, and it remains the shared vocabulary a report and a hosting reviewer can both read. But it is a list of risk categories rather than a test plan, three of the nine families below do not map onto it cleanly, and CERT-In’s own instrument says so. The practical consequence is the last two columns of this table: where the Top 10 runs out, cite a WSTG test identifier for what was done and an ASVS chapter for what was verified. §8(i) supplies the reason underneath all of it — solely tools-based testing should be discouraged as tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure, which is exactly the gap a category list leaves open.

Editions, therefore, everywhere. The mapping below is to the Top 10:2021, named explicitly — a report citing “OWASP Top 10” without a year is ambiguous the moment the list is revised, and it has been. Test identifiers are WSTG 4.2. Chapters are ASVS 5.0.0 of May 2025, which went from fourteen chapters to seventeen and renumbered every requirement from 4.0.

Finding family	OWASP Top 10:2021	WSTG 4.2 test IDs	ASVS 5.0 chapter	How honest the mapping is
01 · Access control and IDOR	A01:2021 — Broken Access Control	WSTG-ATHZ-01 directory traversal, ATHZ-02 bypassing the authorisation schema, ATHZ-03 privilege escalation, ATHZ-04 insecure direct object references.	V8 Authorization, with V4 API and Web Service where the break is on an API.	The cleanest mapping here. Object-level, function-level and field-level failures all sit inside A01, and the Top 10 names insecure direct object references explicitly.
02 · Authentication and session handling	A07:2021 — Identification and Authentication Failures	WSTG-ATHN-01 to 10 and SESS-01 to 09. In particular ATHN-03 weak lock-out, ATHN-07 password policy, ATHN-09 password change or reset, SESS-02 cookie attributes, SESS-03 session fixation, SESS-07 timeout.	V6 Authentication, V7 Session Management, V9 Self-contained Tokens where the session is a JWT.	Clean for credential stuffing, weak recovery flows and session fixation. Strained for token lifetime and concurrent sessions, which the Top 10 does not address.
03 · Injection	A03:2021 — Injection	WSTG-INPV-05 SQL (05.6 NoSQL), INPV-06 LDAP, INPV-07 XML, INPV-11 code, INPV-12 command, INPV-18 server-side template injection. INPV-01 and INPV-02 for reflected and stored cross-site scripting.	V1 Encoding and Sanitization, with V2 Validation and Business Logic.	Real for SQL, NoSQL, OS command, LDAP and XSS, which the 2021 edition folded into A03. Deserialisation is habitually filed here and is not there: CWE-502 is mapped to A08:2021. OWASP maps thirty-three CWEs to A03, and CWE-1336, server-side template injection, is not one of them.
04 · File upload	No single category — usually A04:2021 Insecure Design with A05:2021 Security Misconfiguration	WSTG-BUSL-08 upload of unexpected file types and BUSL-09 upload of malicious files, with CONF-03 file-extension handling for the storage half.	V5 File Handling — a chapter written for this family, which makes it a better citation than a Top 10 number.	Where the mapping stops being real: unrestricted upload has no home of its own in the 2021 edition, and filing it under A03 is stretching.
05 · Security headers and TLS	A05:2021 Security Misconfiguration for headers, A02:2021 Cryptographic Failures for transport	WSTG-CRYP-01 weak transport layer security, CRYP-03 sensitive information over unencrypted channels, CONF-07 HSTS, SESS-02 cookie attributes, CONF-02 platform configuration.	V12 Secure Communication, V13 Configuration, V3 Web Frontend Security for the content security policy.	Two findings merged into one scanner row. Headers are configuration, while weak ciphers, missing HSTS and certificate problems are cryptographic. Splitting them changes who owns the fix.
06 · Exposed administrative interfaces	A05:2021 Security Misconfiguration, frequently with A01:2021	WSTG-CONF-05 enumerate infrastructure and application admin interfaces, with CONF-01, CONF-10 subdomain takeover and ATHN-02 default credentials.	V13 Configuration.	Partly real. Reachability is misconfiguration, but what blocks the certificate is usually the authentication and authorisation behind it, which is A07 and A01.
07 · Verbose errors and information disclosure	A05:2021 Security Misconfiguration, with A09:2021 where logging is involved	WSTG-ERRH-01 improper error handling, ERRH-02 stack traces, CONF-04 old backup files, INFO-05 webpage content review.	V16 Security Logging and Error Handling, with V14 Data Protection where personal data leaked.	Weak. Most disclosure findings are severity-amplifiers rather than standalone Top 10 items.
08 · Outdated and vulnerable components	A06:2021 — Vulnerable and Outdated Components	No dedicated test. Version identification sits in INFO-02 fingerprint web server and INFO-08 fingerprint web application framework.	V15 Secure Coding and Architecture, section V15.2 Security Architecture and Dependencies.	Exact, and the one family where a version number settles the argument. The scanner severity is the unreliable part, because reachability is not assessed by a version check.
09 · Secrets in client-side code	A07:2021 or A02:2021, depending on what the secret is	WSTG-INFO-05 webpage content review, with CLNT-12 browser storage where the secret is held client-side at runtime.	V14 Data Protection and V11 Cryptography for key handling.	No clean home. An embedded key is an authentication failure in effect and a cryptographic one in nature. The Top 10 number matters less than the rotation evidence.

How do the nine families map if the service is an API?

Government estates are increasingly API-first: a mobile client and a web client over one interface, a departmental integration over another, a gateway in front of both. §13.1.1 puts APIs inside the audit scope in terms, and §6(xii) lists application security testing as covering web applications, mobile applications and APIs. OWASP maintains a separate list for that shape, and its 2023 edition splits and names things the web list has nowhere to put. Where an API is in scope, a report that maps only to the web Top 10 describes the wrong attack surface. All nine families are below, including the two where the honest answer is that the API list has no equivalent — which is information, not a gap.

Family	OWASP API Security Top 10 2023	Why it matters that the lists differ
01 · Access control and IDOR	API1:2023 Broken Object Level Authorization, API3:2023 Broken Object Property Level Authorization, API5:2023 Broken Function Level Authorization	Three separate entries where the web list has one. That is the point of citing the API list: object-level, property-level and function-level breaks are distinct tests with distinct fixes, and a report that files all three under A01 hides which of the three was actually exercised.
02 · Authentication and session handling	API2:2023 Broken Authentication, and API4:2023 Unrestricted Resource Consumption for the missing-throttle case	Absent rate limiting on an OTP or reset endpoint is an authentication finding in the web list and a resource-consumption finding in the API list. Both descriptions are right, but the API one names the control you are missing.
03 · Injection	No dedicated entry. The 2019 edition carried API8:2019 Injection, and the 2023 edition dropped it	The clearest illustration of why a list is not a test plan. Injection did not stop mattering on an API — OWASP concluded the community was finding other classes more often, and re-ranked. Cite WSTG test identifiers here and let the API list govern the authorisation and inventory findings it is actually about.
04 · File upload	API8:2023 Security Misconfiguration for the storage and serving half, and API4:2023 Unrestricted Resource Consumption for the missing size, count and rate limits	Split across two entries on the API list, exactly as it is split across two on the web list — which is a sign that the defect is one feature with four independent controls rather than one category on anybody’s list.
05 · Security headers and TLS	API8:2023 Security Misconfiguration	The transport half maps here rather than to a cryptography entry, because the API list has none. Where the finding is a session cookie or a token in transit, the authentication entry API2:2023 is the more accurate citation.
06 · Exposed administrative interfaces	API8:2023 Security Misconfiguration and API9:2023 Improper Inventory Management	API9 is the entry with no web-list equivalent at all, and it is the one that describes the real failure in most Indian government estates: an older version of the API still answering on a host nobody inventoried.
07 · Information disclosure, and dependencies on other services	API10:2023 Unsafe Consumption of APIs, with API7:2023 Server Side Request Forgery	Where the application calls an identity provider, a payment interface or a departmental service, what it trusts in the response is in scope. The web Top 10 has nowhere to put that.
08 · Outdated and vulnerable components	No API-list equivalent	The 2019 edition had API9:2019 Improper Assets Management and the 2023 edition has no components entry at all. Cite A06:2021 from the web list, or the advisory itself — an API list that is silent is not an argument that the finding is out of scope.
09 · Secrets in client-side code	API2:2023 Broken Authentication where the secret authenticates, API8:2023 Security Misconfiguration where it was published by a build or serving mistake	Neither entry describes the disclosure itself, which is why the citation matters less here than the rotation evidence. What the API list does add is the reason a published key is worse on an API: there is no session to invalidate.

The catalogue

The five findings an attacker finds by attacking: access control, authentication, injection, upload, transport

Each family is written the same way: a metadata strip you can triage from, then what it covers, why it blocks issue, what a proper fix looks like with the values attached, the suppression that gets rejected, and the evidence asked for at retest. The organising principle is what the finding is, not which tool printed it.

On those values: where one comes from a published source it is attributed — the password-hashing, HSTS and session-timeout figures are OWASP cheat-sheet recommendations. The rest are defaults that pass without argument in practice, not a standard and not a CERT-In requirement. An auditor will accept a defensible figure and will not accept an unstated one.

01 · Access control and IDOR

Broken access control and insecure direct object references

Exploitable by an ordinary account, and the class tooling structurally cannot find.

How often it blocks	The class most often found open in the CERT-In audits we deliver with our CERT-In empanelled partners. On the public dataset, OWASP records A01:2021 with 318,487 occurrences — the most of any category in that edition — and states that 94 per cent of the applications in the contributed dataset were tested for some form of broken access control, which is a measure of how widely it was looked for rather than of how often it was present
Typical band	High, Critical at scale or where it reaches an administrative function
Usually found by	Two accounts per role and a proxy. Scanners find it by accident
Fix owner	Application team
Typical fix effort	A sprint with one enforcement point, a release cycle without
Where it usually hides	Export and reporting screens, bulk-import endpoints, support-staff workflows, the mobile API that predates the web authorisation layer

What it covers

Object-level: change an identifier, receive somebody else’s record. Function-level: an ordinary user reaching an administrator’s endpoint hidden only by the menu. Field-level: the record is yours, the response carries columns you are not entitled to. Tenant-boundary: the tenant identifier comes from the request. Mass assignment: a role flag set by a payload field the form never sends.

Why it blocks issue

Exploitable by any authenticated user with a browser, needing no tooling and leaving no trace — and in a citizen-facing service the records belong to people who had no choice about using it. One predictable identifier usually means the whole table is enumerable.

What a proper fix looks like, concretely

The decision moves server-side, to the data access layer rather than the controller: every read and write resolves the subject from the session, resolves the object, and asks whether this subject may do this to this object. Deny by default at one enforcement point every route passes through. Per-role allow-lists of writable fields, declared rather than inferred. Unguessable identifiers as a second layer, never the control. A route added without an authorisation annotation must fail closed, and a test should prove it.

The enforcement primitive, by stack

Spring          method security (@PreAuthorize) + a global fallback deny
Django          DRF permission_classes + object-level get_queryset filtering
Express         router-level authorisation middleware, registered on the router
ASP.NET Core    authorization policies with AuthorizationOptions.FallbackPolicy
Rails           Pundit/CanCanCan with verify_authorized as an after_action

The test that proves fail-closed:
  enumerate every route from the router at build time
  fail the build on any route with no authorisation annotation

The names differ by stack, but the property does not. One place every request passes through, denying unless something explicitly permits.

The suppression that gets rejected

Sequential integers swapped for UUIDs. The menu item hidden. A client-side role check while the API keeps answering. The tester’s identifier blocked. A referer check.

Closure evidence at retest

Two accounts of the same role and two of different roles provisioned for the auditor, with a matrix of endpoint against role and expected outcome. The code showing where the check now lives, and a demonstration that an unannotated route is denied.

02 · Authentication and session handling

Weak authentication, password reset and session handling

The login works. That is not the same as the login being sound.

How often it blocks	Common in the CERT-In audits we deliver with our CERT-In empanelled partners, and rarely in the primary login — that is the path every team tested
Typical band	High, Critical on an outright bypass
Usually found by	Manual testing of recovery, enrolment and logout, plus throttle and token-lifetime checks
Fix owner	Application team, with the identity-provider owner
Typical fix effort	Configuration to a sprint, longer where sessions live in more than one place
Where it usually hides	Password-reset and OTP flows, multi-factor enrolment, support impersonation, the mobile session that outlives the web one, a legacy module’s second login

What it covers

Everything between a credential being presented and a session being destroyed: password policy and storage, multi-factor enrolment, lockout and rate limiting, the forgot-password and OTP flows, token generation and transport, timeout and logout, and what happens to a session when a password or privilege changes.

Why it blocks issue

An authentication defect contradicts the certificate at the point where the application decides who someone is, and it multiplies everything else: a medium access-control finding behind a login that can be brute-forced is not a medium.

What a proper fix looks like, concretely

Fix the mechanism, not the path: a predictable reset token becomes a cryptographically random, single-use, short-lived token validated server-side in every flow that issues one. A missing lockout becomes throttling at the identity layer across login, OTP verification and reset alike. Argon2id at the OWASP minimum of 19 MiB, two iterations, one degree of parallelism, or bcrypt at work factor 10 or above. Five failures in a fifteen-minute window with a progressive delay is a default that passes without argument. Session identifiers with at least 64 bits of entropy. OWASP suggests idle timeouts of two to five minutes for high-value applications and fifteen to thirty for low-risk ones, with an absolute timeout of four to eight hours. Cookies Secure and HttpOnly, SameSite=Strict preferred and Lax as fallback, never None without Secure. Invalidate every session on password and role change.

Reference values

Password hashing   Argon2id  m=19456 (19 MiB), t=2, p=1
                   or bcrypt work factor >= 10
Lockout/throttle   5 failed attempts / 15 min, progressive delay,
                   applied to login, OTP verify and reset alike
Session ID entropy >= 64 bits
Idle timeout       2-5 min high-value, 15-30 min low-risk
Absolute timeout   4-8 hours
Reset token        >= 128-bit random, single use, short-lived,
                   validated server-side, invalidated on use

Set-Cookie: session=<id>; Secure; HttpOnly; SameSite=Strict; Path=/

The hashing, timeout and entropy figures are OWASP cheat-sheet recommendations. The throttle window is a default that passes without argument, not a standard.

The suppression that gets rejected

A filter rule blocking the tester’s user agent. A rate limit on only the URL in the finding. Raising token entropy while the token stays valid for a day and reusable. Changing the error message while the timing difference remains.

Closure evidence at retest

The configuration that implements the control — identity-provider policy export, framework session configuration, the throttle with its counter and window visible — plus the code diff and a log sample showing the throttle firing. A screenshot of a locked account shows one attempt rather than the rule.

03 · Injection

SQL injection, command injection and cross-site scripting

Rarer than it used to be, and still a finding that can end an audit on the first day.

How often it blocks	Less common than it was — frameworks parameterise by default. It survives where they did not reach
Typical band	Critical server-side, High for stored cross-site scripting an administrator will view
Usually found by	Manual testing where a scanner reaches, a code read where it does not
Fix owner	Application team
Typical fix effort	Days at one call site, a sprint where the construction is a house pattern
Where it usually hides	Legacy reporting and search screens, exports that shell out, XML ingestion, dynamic ORDER BY and column parameters, fields an administrator reads in a console

What it covers

Untrusted input reaching an interpreter with its structure intact: SQL and NoSQL, operating-system commands, LDAP filters, XPath and XML parsers, template engines, and the browser’s own parser in the case of cross-site scripting, which the 2021 Top 10 folded into this category.

Why it blocks issue

Server-side injection is a whole-system compromise rather than a bounded defect: the database, the file system and often outbound network access follow. Stored cross-site scripting blocks differently — a persistent attack on other users, typically the administrators who review submissions.

What a proper fix looks like, concretely

Parameterise: prepared statements with bound variables for SQL, the driver’s document API for NoSQL, library calls instead of shell invocation. Dynamic ORDER BY and column names take an allow-list rather than a bind. Where a shell is unavoidable, an argument array with an allow-list, never a quoted string. External entity resolution and DTD processing disabled explicitly at the XML parser. Contextual output encoding at render time, with input validation as the second layer rather than the fix. A starting content security policy built from a report-only run, with nonces or hashes if inline script cannot be removed.

Reference configuration

Content-Security-Policy: default-src 'self'; script-src 'self';
  object-src 'none'; base-uri 'self'; frame-ancestors 'none';
  form-action 'self'

SQL          prepared statements with bound variables
ORDER BY /   allow-list of permitted column names — a bind will not
column names work here, and this is where parameterisation is skipped
Shell        argument array + allow-list, never a quoted string
XML parser   external entity resolution and DTD processing disabled
             explicitly, at the parser, not by input filtering
Rendering    contextual output encoding at render time

Start the policy in report-only, read the violation reports for a fortnight, then enforce. A policy enforced on day one is a policy that gets relaxed to unsafe-inline by week two.

The suppression that gets rejected

A blocklist of quotes, semicolons and the word UNION. A filter signature. Escaping in the one screen the report named. Encoding on input so the stored value looks safe while the rendering path stays unencoded.

Closure evidence at retest

The code diff at every call site, plus a repository-wide search showing the unsafe construction no longer appears — one of the few places where a repository-wide search is strong evidence. For cross-site scripting, the policy header as served plus a demonstration that an injected payload renders as text in each context.

04 · File upload

Unrestricted file upload

One feature, four independent controls, and teams routinely implement one of them.

How often it blocks	Common wherever the application accepts a document, which in a citizen-facing service is almost always. First-party observation
Typical band	Critical where the file can be executed, High where it is served back under a trusted domain
Usually found by	Upload, then a direct request for the stored path — a two-step test scanners rarely complete
Fix owner	Application team for validation and naming, platform team for storage
Typical fix effort	A sprint. Moving storage out of the web root is the long pole
Where it usually hides	Grievance and application forms, profile photographs, bulk-import spreadsheets, workflow attachments, the legacy upload endpoint nobody removed

What it covers

The failure is rarely that upload is allowed. It is that the type is trusted from the client-supplied name, that the file lands inside the web root where the server will execute it, that the stored name is attacker-controlled, that there is no size or rate limit, and that archives expand without bounds.

Why it blocks issue

The worst case is remote code execution through a web shell — a hosting compromise rather than an application bug. The second is your infrastructure becoming a distribution point under a trusted domain: a gov.in URL serving an attacker’s payload. The third is stored content that attacks the next reader.

What a proper fix looks like, concretely

Four controls, all of them. Type determined from content against an allow-list of the formats the feature needs, never a blocklist. Storage outside the web root with execution disabled, served back through an application handler with Content-Disposition: attachment, a non-executable Content-Type and X-Content-Type-Options: nosniff. Filenames generated server-side, the client-supplied name kept only as a display label. A per-file ceiling matched to the largest document the feature legitimately needs rather than to the framework default, a per-session count and rate limit, and archive expansion bounded by a total-size cap and a compression-ratio cap — above roughly 100:1 is the usual signal for a decompression bomb. State the numbers you chose.

Worked limits for a grievance-attachment feature

Accepted types     PDF, JPEG, PNG — determined from content, not from
                   the filename or the client-supplied Content-Type
Per-file ceiling   10 MB
Per submission     5 files
Per session        20 files / hour
Archive expansion  total 100 MB, compression ratio cap 100:1
Stored name        server-generated (UUID), client name kept as a label
Storage            outside the web root, execution disabled at the store

Serving the file back, through an application handler:
  Content-Disposition: attachment; filename="<sanitised label>"
  Content-Type: application/octet-stream
  X-Content-Type-Options: nosniff

The numbers are worked defaults for one feature, not a standard. What an auditor rejects is not a number they disagree with — it is the absence of one.

The suppression that gets rejected

Extension blocklists. Client-side validation. Renaming the file but keeping it in the web root. Checking the first bytes while the server still decides executability from the extension. Adding a scanner and leaving the storage location alone.

Closure evidence at retest

A retest that uploads a double extension, a polyglot, a traversal sequence in a filename, and an archive that expands beyond its declared size — then a direct request for the stored path to prove it is not executable. Produce the storage configuration, the serving handler with its headers visible, and the limits as configured.

05 · Security headers and TLS

Missing security headers and weak TLS configuration

The family scanners report most heavily, and the one that stalls audits for the least good reason.

How often it blocks	In almost every report, because a scanner prints the whole set. Three items block, and the rest are hygiene
Typical band	Low to Medium for headers, High for plaintext credentials, a deprecated protocol, or a session cookie without Secure and HttpOnly
Usually found by	An external sweep, verified by reading raw responses rather than a scanner grade
Fix owner	Platform team at the terminating layer, cookie attributes to the application team
Typical fix effort	Hours, except the content security policy, which is a sprint
Where it usually hides	The origin behind the CDN, redirect responses, error pages, API hostnames, any second hostname the service answers on

What it covers

Two things a scanner prints as one block. Transport: protocol versions and cipher suites, certificate chain validity and hostname coverage, HSTS, and whether plaintext is redirected or merely available. Application headers: content security policy, nosniff, frame-ancestors, referrer and permissions policy, version-banner removal. Cookie attributes belong here too.

Why it blocks issue

A missing referrer policy blocks nothing. Three things here do. Credentials over plaintext, or a deprecated protocol version, fails at the transport layer for every user. A session cookie without Secure and HttpOnly turns a minor scripting defect into account takeover. And a policy of unsafe-inline plus wildcard sources, offered as mitigation for cross-site scripting, removes the mitigation being relied on.

What a proper fix looks like, concretely

Transport policy set once at the terminating layer and recorded as code, so it cannot drift per application server. TLS 1.2 as the floor with 1.3 preferred. TLS 1.0, 1.1 and SSL 3.0 disabled, with export, NULL, anonymous, RC4 and 3DES suites. Subject alternative names covering every hostname the service answers on, apex and API host included. All plaintext redirected, then the OWASP cheat sheet’s Strict-Transport-Security: max-age=63072000; includeSubDomains; preload — two years — noting that preload has permanent consequences. Plus nosniff, a frame-ancestors directive rather than a legacy X-Frame-Options header alone, and a referrer policy of strict-origin-when-cross-origin or tighter. Cookie attributes set in the framework session configuration.

Reference response headers and transport floor

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: ...; frame-ancestors 'none'
Permissions-Policy: geolocation=(), camera=(), microphone=()

TLS floor      1.2, with 1.3 preferred
Disabled       SSL 3.0, TLS 1.0, TLS 1.1
Disabled       export, NULL, anonymous, RC4 and 3DES suites
Certificate    SANs covering every hostname answered on,
               apex and API host included
Plaintext      redirected, on every hostname, before HSTS is set

max-age=63072000 is two years, the OWASP cheat-sheet recommendation. preload has consequences that are effectively permanent — set it deliberately, and only once every subdomain is served over TLS.

The suppression that gets rejected

Headers added at the CDN for the tested hostname while the origin stays directly reachable. A policy containing unsafe-inline and a wildcard, which satisfies the scanner and defends nothing. HSTS on a subdomain while the apex still answers on plaintext.

Closure evidence at retest

Raw responses rather than a scanner grade, taken against every hostname in scope including the origin, and against a redirect path as well as a landing page. Provide the terminating-layer configuration, the policy in its enforced form, and evidence that the origin is either not directly reachable or identically configured.

The catalogue, continued

The four findings nobody has to attack to find: exposed admin, information disclosure, outdated components, leaked secrets

These four share a property: they are discovered by enumeration and reading rather than by attack. An external sweep finds the console nobody meant to publish, reading the bundle finds the key, and a version check finds the component. They are cheap for an auditor to find and, for exactly that reason, unforgivable to leave open — anybody can run the same sweep, including the people you do not want running it.

06 · Exposed administrative interfaces

Internet-reachable admin console or management interface

Nobody meant to publish it. It is published.

How often it blocks	Found in a high proportion of the estates swept in the CERT-In audits we deliver with our CERT-In empanelled partners — a first-party observation, not a published statistic — and almost never found first by the team that owns them
Typical band	Critical with default or shared credentials, High on reachability alone
Usually found by	An external sweep — ports, subdomains, certificate transparency, common paths
Fix owner	Platform team, frequently a different organisation from the application team
Typical fix effort	Hours to remove or gate, days where the console is part of the product
Where it usually hides	Alternate ports on the application host, a publicly answering staging hostname, the load balancer’s management interface, log dashboards, CI runners, a debug console left on by a copied environment variable

What it covers

Any management surface reachable from the internet that was designed on the assumption that it would not be: the administrative console, a database tool installed for a migration, the application server’s manager, log dashboards, orchestration endpoints, CI runners, the debug console. Found in the same sweep: source-control directories served as static content, backup archives in the web root, configuration files readable because directory indexing is on.

Why it blocks issue

The effective control was obscurity, and obscurity ends at the first crawl or certificate-transparency lookup. Most ship with default or shared credentials, and several offer file write or code execution as a designed feature. An auditor who finds one needs no exploit — the reachability is the finding.

What a proper fix looks like, concretely

Remove what is not needed, which is most of it. What remains is bound to a private interface or a management network, not to 0.0.0.0, and reached through an authenticated gateway or a VPN, with source restriction at the network layer rather than by a header the client can set. Multi-factor authentication in front, independent of the application’s own. Default credentials changed and default accounts removed, not renamed. Access logged to a separate stream. And an inventory of every administrative surface, refreshed by the same sweep an auditor would run.

The suppression that gets rejected

Changing the port. Moving the path to something unguessable. An IP allow-list at the application layer that a spoofed header can influence. A robots.txt entry — an index of what to attack, not a control.

Closure evidence at retest

A fresh external sweep of the full address range and hostname set in scope, not a check of the single URL in the finding, because the family is defined by discovery rather than exploitation. Produce the network or gateway rule, the removal ticket, and a statement of how administrative surfaces are inventoried going forward.

07 · Verbose errors and information disclosure

Stack traces, debug pages and information disclosure

Rarely fatal on its own. Often the reason another finding is severe.

How often it blocks	Present in some form in almost every report we see, which is a first-party observation rather than a published statistic. Two cases block, and the rest change the severity of what they sit next to
Typical band	Low to Medium, High to Critical for a debug page exposing environment variables, or personal data in a query string
Usually found by	Provoking errors deliberately, plus a read of the served bundle and the response headers
Fix owner	Application team for error handling, platform team for banners and listings
Typical fix effort	Configuration, mostly. Longer where personal data is already in log history
Where it usually hides	Error paths nobody tested, responses distinguishing "no such user" from "wrong password", generated document metadata, editor and backup files in the web root, query strings of pages reached from an email or SMS

What it covers

Stack traces rendered to the user, database errors carrying table and column names, debug pages listing environment variables, version banners, directory listings, backup files in the web root, and API errors distinguishing "no such user" from "wrong password". More serious, and in the same family: personal data in URLs that reach logs, analytics and referer headers.

Why it blocks issue

Two of these block on their own. A debug interface exposing environment variables is a credential disclosure and is treated as one. Personal data leaving through a query string is a data-protection failure a government application cannot carry into production. The rest change the severity of what they sit next to.

What a proper fix looks like, concretely

One generic error page and one generic API error body, carrying a random correlation identifier and nothing else — no exception class, no table name, no path — with the detail written under the same identifier to a server-side log the user cannot reach. Debug modes disabled by build configuration, so a misconfigured deployment cannot re-enable them. Directory indexing off. Server, framework and language version headers stripped at the terminating layer. Authentication errors identical for an unknown user and a wrong password in body, status code and response time. No identifier, token or personal attribute in a query string, and a documented review of what the log pipeline already captured.

The suppression that gets rejected

Catching the exception the tester triggered. Replacing the error page while the framework still returns a stack trace on a different exception class. Removing the version banner from one header while another carries it.

Closure evidence at retest

The auditor will provoke errors deliberately — malformed content types, oversized payloads, type-confused parameters, a route that does not exist. Produce the build configuration that disables debug output, paired samples of the log entry and the opaque response, and the remediation of historical logs where personal data was in transit.

08 · Outdated and vulnerable components

Known-vulnerable libraries, runtimes and base images

Usually the longest section of a report, and the one where argument is legitimate.

How often it blocks	In essentially every report, because the list is generated rather than found. The question is which entries are reachable
Typical band	Taken from the advisory by default, and the band most often re-graded once reachability is assessed
Usually found by	A version check against an advisory database, plus an independent fingerprint of the live service
Fix owner	Application team for libraries, platform team for runtime, server and base image
Typical fix effort	A dependency bump is hours, but a runtime major upgrade is a release cycle — start it first
Where it usually hides	Transitive dependencies two levels down, a base image never rebuilt since containerisation, a package pinned during a migration, the gap between the manifest and what is running

What it covers

Third-party code with known vulnerabilities: framework and runtime versions, direct and transitive dependencies, the web and application server, the database engine, container base images, and the OS packages beneath. What the generated list does not say is whether the vulnerable code path is reachable in your application — the question that decides what closure means.

Why it blocks issue

A known, remotely exploitable vulnerability in a reachable path is the same as writing that vulnerability yourself, and an application on an unsupported runtime cannot receive security fixes at all. This is also the family where the instrument’s mapping rule bites hardest: §16.2(ii) requires every observation to carry a CWE and a CVE, so a component finding arrives with its advisory identifier attached and the argument moves straight to reachability. §16.3(iii) requires the report to state closure timelines by severity — a reporting requirement on the auditor, not a deadline imposed on you.

What a proper fix looks like, concretely

Upgrade in the order the risk dictates rather than the order the list is printed in: runtime and server first, then direct dependencies with reachable advisories, then transitive ones resolved by upgrading the parent. A runtime and server still receiving security fixes from the vendor is the one line here that is not negotiable. A software bill of materials generated from the built artefact on every build, retained with the release. A scan on every build and on a schedule. For anything deferred: a written reachability analysis naming the vulnerable function and showing it is not called, a compensating control, an owner and a date.

The suppression that gets rejected

Marking an advisory not applicable with no reachability analysis behind it. Pinning a version so the scanner stops reporting it. Removing the version banner. Upgrading the package in the manifest while the running container still carries the old build.

Closure evidence at retest

A bill of materials generated from the built artefact rather than the source manifest, so the evidence describes what is running. A before-and-after scan of the same artefact, with the scanner and its database date stated. The auditor will fingerprint the live service independently, and a discrepancy is its own finding.

09 · Secrets in client-side code and repositories

Hard-coded API keys and credentials in client code

Found by reading, not by testing — and the only family where fixing the code is not enough.

How often it blocks	Less common than the rest, and disproportionately serious — the disclosure has already happened by the time it is found
Typical band	High to Critical, set by what the credential opens rather than by where it was found
Usually found by	Reading the bundle, the mobile binary, the source maps and repository history
Fix owner	Application team for the code, the credential’s administrator for the rotation
Typical fix effort	Rotation is hours and comes first. Proxying server-side is a sprint. Purging history is a project
Where it usually hides	Source maps published beside a minified bundle, a build signed with a committed key, a static config file on the asset path, a key removed from the head but not from history, a shared account whose password sits in a wiki

What it covers

Credentials that have left the server: keys and tokens in JavaScript bundles, mobile binaries and source maps, database strings and cloud keys committed to a repository (including in history after removal from the head), keys in configuration files served as static assets, and signing keys in a mobile build. It extends to hard-coded default credentials and shared service accounts.

Why it blocks issue

The credential is already disclosed. Every user who loaded the page has it, every copy of the repository contains it, and there is no way to establish that it has not been used. The severity does not depend on demonstrating misuse — the disclosure is the event.

What a proper fix looks like, concretely

Rotate first, then fix the code, in that order, because the order is the whole point: code changes stop the next disclosure and do nothing about this one. Rotation completed and the old credential revoked, not merely replaced, before any code change is discussed. The secret held in a server-side store and read at runtime with a short-lived credential where the platform issues one. Every third-party call that needs a key proxied through your own backend. Source maps not published to production, or published to an authenticated path. Secret scanning at pre-commit and as a build gate that fails the build rather than warning.

The suppression that gets rejected

Obfuscating or base64-encoding the key. Removing it from the current commit while it remains in history. Restricting the key by referer or origin, which is client-supplied. Replacing the key and leaving the old one active.

Closure evidence at retest

Evidence of rotation with a timestamp, from the system that issued the credential — not from the code. Then the code change, the secret-store configuration, and a fresh scan of the built bundle and of repository history. Expect the auditor to search the deployed assets themselves, and to ask what the old credential can still do.

The tenth case

If the application is a mobile app

The nine families apply to the API behind a mobile client exactly as they apply to a web application — and a mobile audit adds failure modes with no web equivalent, because the artefact runs on a device you do not control. CERT-In treats it as its own class: §6(xiii) of the 2025 audit policy guidelines lists Mobile Application Security Auditing separately from web application testing, and §13.2.3 requires version-specific details of mobile applications to appear in both the scope and the report. OWASP maintains a separate standard, and the same edition discipline applies to it as to everything else on this page. The eight control groups below — MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE and MASVS-PRIVACY — are MASVS v2.1.0 of January 2024, while v2.0.0 had seven, without MASVS-PRIVACY. The testing procedures sit in the MASTG, whose current release is v2.0.0 of June 2026 and which renumbered its test identifiers, so a scope of work should name the MASTG version alongside the MASVS one or the identifiers in it will not resolve.

Sensitive data in local storage

MASVS-STORAGE

Tokens, personal data or a cached record in shared preferences, a plist, an unencrypted database or a log. Evidence: storage inspected on a device after a representative session, plus the keystore or keychain configuration for anything that persists.

Exported components and deep links

MASVS-PLATFORM

An activity, service, receiver or provider exported without need, or a deep link that acts without re-establishing who is asking. Evidence: the manifest with export flags visible, and a demonstration that an outside intent cannot drive the flow.

WebView configuration

MASVS-PLATFORM, with MASVS-CODE

JavaScript enabled with a native bridge exposed, file access allowed, mixed content permitted, or certificate errors ignored. Evidence: the WebView settings as constructed in code, and the bridge surface enumerated.

Transport and certificate validation

MASVS-NETWORK

Plaintext permitted by the network security configuration, a trust manager that accepts anything, or absent pinning where the threat model calls for it. Evidence: the network security or App Transport Security configuration, and an interception attempt that fails.

Debuggable or backup-enabled builds

MASVS-RESILIENCE, with MASVS-STORAGE for backup

A release build still debuggable, permitting full backup, or shipping symbol files. Evidence: the flags read back from the artefact that was submitted, not from the project file.

Secrets in the binary

MASVS-CRYPTO, with MASVS-RESILIENCE

Keys, signing material or endpoint credentials extractable by unpacking the artefact. Same rule as family 09: rotate first, then fix. Evidence: rotation timestamp, then a fresh scan of the rebuilt artefact.

The tested build is not the submitted build

No MASVS group — an artefact-identity control, not a code control

The point with no web equivalent. A mobile audit tests one artefact, and what reaches the store must be that artefact. Evidence: the hash of the tested APK or IPA in the report, and the same hash on the build submitted.

The last item catches teams who did everything else right. A web audit tests a deployment, while a mobile audit tests an artefact. Record the hash at the point of testing and submit that exact file — which is also what §15.2.3(ii) asks for, application hash values and version numbers obtained from the auditee and included in the report, and what §9.5(i) asks to be carried through onto the certificate itself.

Worked example

A first report, a suppression, and a second retest

A suppression is not usually dishonesty. It is a team under deadline fixing what the report described, because the report described a path and nobody translated it into a mechanism. The test that separates the two: if a colleague who had never read the report tried the same class of attack from a fresh angle, would they get through? What follows is an illustrative composite — not a client, with dates and counts constructed to show the shape. A departmental grievance-management application, forty screens and one mobile client over a shared API, audited before a production hosting review.

2 Mar	Report issued	Twenty-two findings: two high, six medium, fourteen low and informational. The highs are an object-level authorisation break on a case-detail endpoint, and an administrative console answering on port 8443 of the application host with a shared password held by four people.
13 Mar	Eleven days of remediation	The console is bound to the management network and put behind the departmental gateway with multi-factor authentication — a day’s work, because nobody had owned the configuration. The authorisation break is fixed by adding an ownership check to the case-detail controller. A closure register goes over with nine rows.
19 Mar	First retest	The console closure holds: a fresh sweep of the full hostname and port range finds nothing. The authorisation fix does not. The auditor does not repeat the reported request — they call the case-export endpoint, which returns the same records in bulk and never passed through the changed controller.
2 Apr	Second remediation round	The decision moves to the data access layer, deny-by-default, every route passing through it, with a test that fails when a route is added without an annotation. Two more endpoints found during the move are volunteered in the register rather than left to be discovered.
9 Apr	Second retest, closure	The auditor walks the matrix with two accounts per role, then attacks from outside it: a route added after the fix, a sibling parameter, a different content type. All deny. Both highs close, and the six mediums are carried with owners and dates.
16 Apr	Certificate issued	Forty-five days from report to certificate, against a three-week remediation window originally planned. The whole overrun is the second retest cycle, and that cycle exists because the first fix was written at the path in the report rather than at the mechanism.

The closure register row, as first submitted

STH-2026-014 · High · CVSS AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N 6.5 · CWE-639 · no CVE · Object-level authorisation not enforced on /api/v1/grievance/{id} · Remediation: ownership check added to the case-detail controller · Evidence: merge request 402 diff · Environment: staging · Retest: request record 8841 as citizen account A.

The auditor’s retest note

Reported request denied as expected. Case-export endpoint /api/v1/grievance/export returned 412 records belonging to other complainants when called with citizen account A. Remediation applied at the controller, not at the data access layer. Finding remains open. Second affected component added. Closure evidence taken on staging only. Follow-up audit to be repeated on production before the final report issues.

Notice what the register row did. It proposed the retest as the report had described the finding — one record, one endpoint — the shape a suppression takes even when the fix is genuine. The auditor asked instead where else the same data is returned. The fix that closed it was smaller in code than the first: one enforcement point, plus a test that fails when a route bypasses it.

The retest

What happens at a safe-to-host retest, which the instrument calls a follow-up audit

First, the vocabulary, because the word you use decides whether your auditor understands you. What this page has been calling a retest is what the Comprehensive Cyber Security Audit Policy Guidelines call a follow-up audit, and the deliverable that carries critical and high observations through to the end is the Final Outcome Report. §9.3 puts follow-up audits in the scope or the RFP from the outset rather than treating them as an afterthought, and §13.1.1 says the same. Use the instrument’s words in writing and your correspondence lines up with your auditor’s file.

A follow-up audit is a smaller engagement with a narrower question, run against the same environment discipline as the first round: the fixed build, deployed to the environment the auditor tested. Its scope is the open findings plus whatever the fix touched — frequently wider, because a change to a shared authorisation layer affects every route passing through it. One thing to settle before the first round starts, not after it: §16.3(v) contemplates the final report issuing after closure and completion of the follow-up audit of the application hosted on the production environment, which is why closure evidence produced only on staging is so often sent back. Where the audit is limited to staging, the same clause requires the report to say the audit was not conducted on production — and a hosting reviewer reads that sentence.

You will not usually hear about a critical finding for the first time in the report. §16.3(ii) requires critical and high findings to be notified to the auditee during the course of the audit on an as-and-when-found basis, and repeated in the Final Outcome Report. That is calendar time handed to you, and it is regularly wasted because the call reaches a shared mailbox. Agree a named recipient and a channel for those notifications before testing starts — the same discipline the rules of engagement apply to the rest of the auditor’s communications.

The auditor works from a closure register rather than from a conversation. It is what lets a finding be closed on a reasoned statement rather than on an assurance, and it is the guidelines’ objective-evidence requirement seen from your side of the table. Nobody will send you a template. Prepare it yourself, one row per finding, before the retest is booked.

The closure register, field by field

Eleven columns, one row per finding. The example values continue the observation from the severity section above, so the two artefacts can be read against each other.

Field	Why the auditor wants it	Example value
Original identifier and title	So your row joins to their report without interpretation. Renaming the finding adds a week.	STH-2026-014 — Object-level authorisation not enforced
Severity as issued	As the auditor graded it. Re-grading belongs in a separate, argued column.	High
CWE and CVE as issued	Carried across unchanged from the observation, because §16.2(ii) put them there. It is the join key that survives a renumbered report.	CWE-639, no CVE
Affected components	Including siblings you found and fixed yourself. Volunteering those shortens the retest.	/grievance/{id}, /grievance/export, /v2/grievance/{id}
Remediation summary	One paragraph on the mechanism changed. If it describes a path, you know what the retest will find.	Authorisation moved to the data access layer, deny-by-default. All three routes pass through it.
Evidence artefact and source	Named file, and the system it came from. Evidence from the implementing system outranks a description of it.	Merge request 481 diff. Matrix test run from the CI job.
Retest method proposed	Proposing the test is not marking your own work, and it removes a round of email.	Account A against records owned by B, on all three routes and on a route added after the fix.
Environment the fix is deployed in	§16.3(v) contemplates the final report issuing after closure and completion of the follow-up audit of the application hosted on the production environment. Closure evidence from staging alone is the commonest reason a round is repeated.	Production, release 4.2.1, deployed 8 Apr. Staging identical.
Result and date closed	Blank until the auditor fills it. A register arriving pre-marked closed is read sceptically.	(left for the auditor)
Residual risk	Where the fix is interim rather than structural, say so. An undeclared interim fix found at retest is its own finding.	None. Structural fix.
Owner	A person, not a team mailbox. The retest produces questions and they need a destination.	Grievance module tech lead

Two conventions. Leave the result column blank for the auditor — a register arriving pre-marked closed reads as a request rather than a record. And volunteer the sibling surfaces you found and fixed: a register naming three affected components where the report named one is the clearest signal that the fix was written at the mechanism.

Three behaviours surprise teams the first time. The auditor varies the proof rather than repeating it, so a fix narrowed to the reported request will fail. The auditor may widen scope after a critical finding, because one instance of a pattern implies others. And where an edge filter sits in front, the auditor will try to reach the application around it. None of this is adversarial: it is the difference between verifying a fix and observing an absence.

What a follow-up audit cannot do is answer a question the first round was never scoped to ask — and denial-of-service resilience is the usual example, for a reason worth stating precisely. The 2018 guidelines direct auditors to refrain from distributed denial-of-service testing over the internet and from any form of flood testing. The 2025 guidelines do not prohibit it: §15.2.2(ii) requires explicit written permission before DoS, DDoS or flood testing over the internet, and §15.2.2(iv) directs that in critical environments where availability is a top priority, testing should be conducted passively to avoid downtime or service disruption. So it is a test the department can authorise and usually chooses not to. Where it has not been authorised, availability evidence is architecture and configuration produced deliberately — not a result the engagement was ever going to generate. Decide that at scoping and record the decision, rather than discovering at retest that nobody asked.

Not a vulnerability

Why safe-to-host audits stall for reasons that are not vulnerabilities

These cost more calendar time than the technical catalogue above, none of them appear in a vulnerability list, and every one is preventable in the week before testing starts. The middle column is what the instruments actually say, cited by section: the Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, 25 July 2025) unless another document is named. Every row here is governed by a clause — which is the useful part, because a clause is something both sides can read. What the auditor may, must and may only do on written permission is set out in the empanelled auditor’s rules of engagement. Several of the rows below — the scope that was smaller than the application, the single account, the half-configured staging instance — trace back to one decision taken weeks earlier, which is why scoping a VAPT so the result means something is the page to read before this one rather than after it.

Blocker	Why it stalls the engagement	What to have ready	Who provides it
The wrong environment was offered	Both instruments are explicit. The auditor tests on the staging or testing environment provided by the hosting service provider before issuing the certificate, and the environment — Test, Development, UAT, Pre-Production or Production — must be named in the report (§15.2.3(i) and (ii)). §16.3(v) adds that where the scope was limited to staging, the report must state that the audit was not conducted on production. A half-configured instance produces a certificate that does not describe the thing being hosted.	A staging environment mirroring production in configuration, not only in code: same terminating layer, headers, storage, and integrations or documented stubs.	Hosting service provider, with the platform team
The scope was smaller than the application	One hostname when the service spans three. The web application named while the mobile client talks to the same API. The administrative console excluded as "internal". §13.1.1 puts web and mobile applications, APIs, cloud, databases, hosting infrastructure and code review inside the scope, derived from a consolidated and updated asset inventory — and §13.2.3(ii)(b) requires the date to which that inventory was updated to appear in the report. The parts left out do not become safe, they become undescribed.	A written scope as hostnames, base paths, API endpoints, mobile builds and administrative interfaces, checked against your own enumeration of the estate.	Application owner, signed off by the department
Credentials and test data never arrived	Supply one administrator account and testing runs unauthenticated by default — then someone reads the thin report and asks why authorisation was not tested. It costs more than calendar time: §10.1(ii) requires in-scope assets the auditor could not reach to be named in the report with the reason, and brought to CERT-In’s notice. Provisioning accounts is a short task that routinely costs a week.	Two accounts per role, realistic data, no expiry inside the window, and a role-versus-endpoint matrix.	Application team
Approvals for the testing itself were not obtained	Written approvals are required before penetration tests and tool installation, with installation in the presence of the auditee system administrator, removal afterwards with auditee acceptance, and a tool list with its licence position. §13.2.2(iv) goes further: the auditing organisation must understand the origin and functionality of its tools, test them in a controlled environment first, and have those results formally reviewed and approved by an authorised representative of the auditee. Separately, and as practice rather than a written requirement: on a shared platform the platform owner approves too.	Signed testing authorisation, the tool list with its licence confirmation, a named system administrator, and the platform owner’s consent.	Auditee, auditor and platform owner jointly
The build changed during the audit	A release shipped mid-engagement, so the tested artefact is not the hosted artefact. §15.2.3(ii) requires application hash values and version numbers to be obtained from the auditee and included in the report, and §9.5(i) requires hashes, versions and timestamps to be prominently featured in the audit certificate and reports — and asks the developer to avoid code changes to the audited application after the certificate issues. The auditor cannot certify what they did not test.	A tagged release deployed to the test environment and held until issue, with the tag and artefact hash recorded.	Application team
Nobody decided whether denial-of-service testing was in or out	The two instruments differ, and assuming the older one costs you the choice. The 2018 guidelines direct auditors to refrain from distributed denial-of-service testing over the internet and from any form of flood testing. The 2025 guidelines do not prohibit it: §15.2.2(ii) requires explicit written permission before DoS, DDoS or flood testing over the internet — a permissioned activity, not a banned one — while §15.2.2(iv) directs that in critical environments where availability is a top priority, testing should be conducted passively to avoid downtime. Most safe-to-host engagements do not run it, and that should be a decision on the record rather than an assumption. Exploiting a discovered breach is a separate matter: it is reported immediately to the auditee and to CERT-In under §15.2.2(i), and the engagement becomes an incident response.	A written decision on denial-of-service testing before the window opens — permission granted with its conditions, or a scope recording that availability is evidenced from architecture and configuration instead.	Platform team
Data-handling terms were not settled	Auditee data is stored only on systems located in India, encrypted on auditor laptops, wiped afterwards so that it cannot be retrieved by any known forensic technique, and not shared with an overseas partner unless specifically authorised — with no mirroring outside the country. §10.3 adds the parts teams do not think to ask for: a formal certificate of deletion to the auditee, and retention for one year from completion of the project where the agreement is silent. §14.1(ii) makes the audit engagement letter the named instrument all of this belongs in.	Data-handling terms in the audit engagement letter, the reporting portal’s hosting region confirmed, the retention period stated rather than left silent, and the certificate of deletion asked for in writing at the start.	Auditee and auditor, before commencement
Previous findings were never actually closed	A re-audit begins with the prior report, and not as a courtesy: §15.2.1(iii) requires the auditing organisation to revalidate observations from the previous audit cycle and to record anything unresolved as a repeat observation in the current one. A finding marked closed on assurance rather than on evidence therefore comes back with a history attached — worse than a new finding of the same severity.	The previous report, the closure register that accompanied it, and the evidence each closure rested on.	Application team, from the last engagement

The 2018 guidelines make reducing the expectation gap an explicit duty: the audit process, the artefacts and the deliverables are to be explained in detail before the engagement, and the deliverable structure agreed before commencement. The 2025 guidelines give that duty an instrument — §14.1(ii) requires the agreed terms to be documented in an audit engagement letter, reviewed and signed by authorised representatives of both organisations and serving as a binding reference point throughout. §14.2 then requires scope revisions to be made in writing, with their impact on timelines, resources and deliverables evaluated by both parties and recorded as an addendum. §14.3 names the three things that legitimately trigger a revision — previously unidentified systems presenting significant risk, changes in organisational structure, ownership or the regulatory environment, and a security incident during the audit period. If nobody has walked you through what the report will contain and what the follow-up audit will require, ask before that letter is signed.

The Indian instrument

Findings that come from the Directions, not from OWASP

A safe-to-host certificate is not issued against the CERT-In Directions of 28 April 2022 — but they are inside the audit anyway. §15.2.1(iv) of the 2025 audit policy guidelines requires the auditing organisation to include verification of compliance with those Directions in every audit assignment, with the findings and supporting evidence in the audit report. So where the entity falls inside their scope — service providers, intermediaries, data centres, body corporate and Government organisations — four obligations surface in a review that no proxy will find: clock synchronisation to the NTP server of NIC or NPL under Direction (i), a current point of contact under Direction (iii), the capability to report an Annexure I incident to CERT-In within six hours under Direction (ii), and logs under Direction (iv). A fifth applies to a narrower class: Direction (v) requires data centres, virtual private server providers, cloud service providers and VPN service providers to register and maintain subscriber and customer records — validated names and addresses, the period of hire, IP addresses, onboarding email and timestamp, purpose and ownership pattern — for five years or longer, after any cancellation or withdrawal of registration. The Directions were issued under sub-section (6) of section 70B of the Information Technology Act, 2000, and state that non-compliance may invite punitive action under sub-section (7). They are taken apart clause by clause in the 2022 Directions explained.

One of those four is routinely over-read, at real cost. Direction (iv) says logs of all ICT systems shall be enabled and maintained securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction. Read alone, that sends departments into a log-storage migration. CERT-In’s own FAQ of May 2022, published alongside the Directions on its site, answers the point directly at question 35: “The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time.” The FAQ says of itself that it is not a legal document and does not replace, amend or alter the IT Act or the CERT-In Rules, 2013, so treat it as CERT-In’s published reading rather than as the instrument — and keep the evidence that you can in fact produce the logs in reasonable time, which is the condition the answer turns on.

One point matters for applications that use machine learning. Annexure I lists twenty mandatorily reportable incident types, and the twentieth is attacks or malicious or suspicious activities affecting systems, software and applications related to artificial intelligence and machine learning. An AI feature inside a citizen-facing service therefore already sits inside a reportable incident class.

Before the auditor arrives

The pre-audit pass you can run on yourself

Everything in this list is something an auditor will do to you. Doing it first converts a blocking finding into a sprint ticket, and the order matters — each step removes work from the ones below it.

01 Fix the artefact first. Tag the release that will be tested, deploy exactly that tag to the environment the auditor will test, and hold it. A moving target is the commonest cause of over-run.
02 Write the scope down as hostnames, base paths, API endpoints, mobile builds and administrative interfaces, then walk the deployed estate and check it is complete, running the same subdomain and certificate-transparency enumeration an auditor will run.
03 Provision accounts: two per role, realistic data, no expiry inside the test window, and a documented role matrix saying what each role should reach. That matrix also closes the access-control findings later.
04 Sweep your own perimeter for management surfaces — every open port, hostname and alternate path: consoles, dashboards, runners, debug endpoints, version-control directories, backup files. This removes more blocking findings than anything else here.
05 Run an authenticated pass against your own access-control matrix. Take a session for role A, call role B’s endpoints, change identifiers in URLs and bodies, add fields the form never sends. No scanner finds this, but two people with a proxy and an afternoon find most of it.
06 Generate a bill of materials from the built artefact — not the source manifest — scan it, and deal with runtime and server versions first. Where something cannot be upgraded, write the reachability analysis now.
07 Search the built bundle, the mobile binary, the source maps and repository history for secrets, rotate everything you find before touching the code, and add a pre-commit and build-time check. Then set transport and header policy once, at the terminating layer, verified against every hostname in scope including the origin.
08 Settle the operational preconditions in writing, in the audit engagement letter — which §14.1(ii) makes a named instrument, reviewed and signed by authorised representatives of both organisations and binding throughout: testing approvals, the tool list and its licence position, the named system administrator for tool installation and removal, the data-handling terms including India-only storage, the retention period and the certificate of deletion, whether denial-of-service testing is permitted in writing under §15.2.2(ii), how many follow-up audits are in scope, and the deliverable structure, which the guidelines expect to be agreed before the engagement commences.
09 Close the loop on the parts of the estate that are not the application, because §15.2.1(iv) puts verification of compliance with the Directions of 28 April 2022 into every audit assignment: clock synchronisation to the NTP server of NIC or NPL under Direction (i), a rolling 180 days of logs under Direction (iv), a current point of contact under Direction (iii), and a named person who can report an Annexure I incident within six hours under Direction (ii). On the logs, read the Direction with CERT-In’s own FAQ of May 2022 before re-architecting anything: Direction (iv) says the logs shall be maintained within the Indian jurisdiction, and question 35 of the FAQ answers that "the logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time". The FAQ states of itself that it is not a legal document, so treat it as CERT-In’s published reading rather than as the instrument.

Steps four and five pay for themselves several times over. For the overall path to a certificate, see how to get a safe-to-host certificate and, for government applications specifically, GIGW compliance before go-live.

The audit failed. Now what.

The week after the report lands, in order

Nothing has been refused. Issue is deferred until the blocking findings are closed, and the sequence below is the one that avoids a second remediation round. The order is the content: steps two and three change what steps four to nine are worth doing, and step five is the one teams skip under deadline — which is exactly how a fix ends up written at a path.

01 Separate what blocks from what is carried, before anybody starts fixing. Blocking findings are the ones that would contradict the statement the certificate makes about the tested build in the environment the report names. Everything else is carried with an owner and a date, and §16.3(iii) requires the report to state those closure timelines by severity.
02 Identify which blocking findings are not yours. Where the application sits on a web server owned and operated by somebody else, §13.1.5 puts the server, its operating system, the hosting software and the backend database software with that organisation. A finding in that column moves at the platform owner’s pace, so it needs an owner outside your team on day one, not in week three.
03 Put a named person and a date on every row, including the carried ones. A team mailbox is not an owner. The retest produces questions and they need a destination.
04 Ask the auditor four questions in writing, and get the answers into the engagement record: what the retest scope will be, how many follow-up audits the engagement includes, what counts as a reopened finding, and whether closure evidence has to come from production. The last one matters most — §16.3(v) contemplates the final report issuing after the follow-up audit of the application hosted on the production environment.
05 Translate every finding from a path into a mechanism before writing any code. The question to answer for each is not "how do we make this request fail" but "where is the decision made, and does every route reach it". This is the step that decides whether there is a second retest.
06 Freeze the artefact again. Tag the remediated release, deploy exactly that tag, hold it, and record the hash and version — §15.2.3(ii) requires those to be obtained from the auditee and included in the report, and §9.5(i) asks for them in the certificate too.
07 Attack your own fix from an angle the report did not describe: a sibling endpoint, a different content type, a route added after the change, a different encoding. If a colleague who never read the report can get through, the retest will.
08 Build the closure register before booking the retest, one row per finding, carrying the original identifier, the severity, the CWE and CVE as issued, the mechanism changed, the evidence artefact and its source system, the environment the fix is deployed in, and the retest you propose. Leave the result column blank.
09 Volunteer the sibling components you found and fixed yourself. A register naming three affected components where the report named one is the clearest signal available that the fix was written at the mechanism — and it shortens the retest rather than lengthening it.

One thing not on that list, because it is a decision rather than a task: do not renumber the findings. The auditor’s identifiers are the join key between their report, your register and the next audit cycle — and §15.2.1(iii) requires the next cycle to revalidate this cycle’s observations and record anything unresolved as a repeat observation. A renumbered register costs a week and gains nothing.

How the roles divide

Who tests, who signs, who fixes

Remediation belongs to the people who own the code and the platform, testing and the report to the auditor, and the certificate to an organisation entitled to issue it — for the government safe-to-host requirement, auditors empanelled by CERT-In or STQC, or auditors of STQC or NIC. Those roles do not overlap. Which organisations qualify, and how to check one, is set out in who can issue safe-to-host certificates.

“Who signs off our closure?” has a published answer, and it is more specific than most departments expect. §9.5(iii) of the 2025 guidelines sets out a three-signature chain for the report: signed by the auditors who conducted the audit (and only by manpower declared to CERT-In in the organisation’s snapshot information), then reviewed and signed by a designated reviewer from mid-management who is not part of the audit team, then authorised and signed by the head of the auditing organisation. The audit certificate itself carries two signatures — the Lead Auditor and the head of the auditing organisation. Behind that sits §15.2.5(iii), the maker-checker rule: a separate verification team reviews and validates the audit team’s work, which is the 2018 guidelines’ Red Team over White Team expectation restated.

There is a check on your side of that, and it belongs here because a name on the report outside the declared manpower is itself a defect. §12.2(iii) requires the auditee to verify the identity, identity cards and designations of the people who turn up against the manpower the auditing organisation has declared to CERT-In, and says auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice. Ask for the names at kick-off, check them against the published snapshot information, and check the signatures on the report against the same list at the end.

The conflict-of-interest definition in §5 of the 2025 guidelines expressly covers the same entity implementing controls and auditing them, or auditing while responsible for remediation. §7 puts it in the money as well: payments to the auditing organisation should not be contingent on the outcome of the audit, favourable or unfavourable, nor tied to the submission or approval of any closure report.

How we work

We deliver CERT-In audits

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. A safe-to-host audit is one of them, and the nine finding families above are what it usually turns on. See how a CERT-In audit runs with us.

Provenance

The primary sources, named and linked

Every CERT-In, GIGW and OWASP statement on this page comes from one of the documents below, read directly rather than from a secondary summary, and cited by section where the document has sections. Where a claim describes practice rather than an instrument — how auditors behave, how often a family is found open — it is written as practice and attributed as first-party observation, because CERT-In publishes no findings statistics.

CERT-In, Comprehensive Cyber Security Audit Policy Guidelines cert-in.org.inVersion 1.0, 25 July 2025. Indian Computer Emergency Response Team, Ministry of Electronics and Information Technology. Binding, in its own words, on all CERT-In empanelled auditing organizations and auditee entities covered under the relevant provisions. The current instrument, and the one this page cites by section throughout.Relied on for Severity method and mapping (§16.2(ii): CVSS, EPSS, CWE, CVE), the board-facing executive summary (§16.2(i)), notification of critical and high findings as and when found (§16.3(ii)), closure timelines by severity (§16.3(iii)), the final report after closure and the follow-up audit on production (§16.3(v)), immediate reporting of high-risk findings (§16.4 to the auditee, §15.2.2(i) to the auditee and CERT-In), scope (§13.1.1) and the asset-inventory date (§13.2.3(ii)(b)), the definition of Minor and Major Change (§13.1.2), responsibility where the application is hosted on another party’s server (§13.1.5), the audit engagement letter and scope revisions (§14.1(ii), §14.2, §14.3), the test plan carrying calendar time and man-hours (§13.2.2(ii)), tooling tested in a controlled environment with auditee sign-off (§13.2.2(iv)), permissioned denial-of-service testing (§15.2.2(ii)) and passive testing where availability is critical (§15.2.2(iv)), the environment rules (§15.2.3), repeat observations (§15.2.1(iii)), the verification team (§15.2.5(iii)), the signature architecture (§9.5(iii)), risk treatment authority (§9.2), inaccessible assets (§10.1(ii)), data handling and the certificate of deletion (§10.3), the five-day submission (§10.6), verification of the 2022 Directions in every assignment (§15.2.1(iv)), and the statement that limited lists such as the OWASP Top 10 are not audit standards (§8).
CERT-In, Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment cert-in.org.inVersion 7.2, April 2024.Relied on for Clause 3.2.1 (details of every audit with auditee details, and critical vulnerabilities left unfixed even during follow-up audits) and clause 3.2.2 (the audit report and audit metadata to CERT-In within five days of completion, with auditee details). Annexure I, item 20: reports include all unknowns clearly marked as unknowns. Annexure II: the audit report content format.
CERT-In, Guidelines for CERT-In Empanelled Information Security Auditing Organizations cert-in.org.inVersion 3.0, May 2018, six pages, under three headings: PEOPLE, TECHNICAL and PROCESS. Superseded in substance by the 2025 policy guidelines on every point where the two speak to the same question. Cited here only for what it carries and the later document does not.Relied on for The expectation gap as an explicit duty, the deliverable structure agreed with the auditee before commencement, observations supported by objective evidence compiled with the report, the quarterly report to CERT-In, the verification (Red) team reviewing the audit team, and the 2018 wording on refraining from distributed denial-of-service and flood testing, which the 2025 guidelines replaced with a written-permission rule.
Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 cert-in.org.inNo. 20(3)/2022-CERT-In, MeitY, 28 April 2022, with Annexure I and Annexure II. Effective 60 days after issue. The extension order of 27 June 2022 makes them effective on 25 September 2022 for MSMEs, and on the same date for the validation limb of paragraph (v)(a) and (v)(f) for data centres, VPS, cloud and VPN service providers. Cited here as Direction (i) to (v).Relied on for Clock synchronisation to NIC or NPL (i), six-hour incident reporting and the twenty Annexure I incident types (ii), the point of contact (iii), 180 days of logs (iv), and five-year retention of subscriber, customer and KYC records by data centres, VPS, cloud and VPN providers (v).
CERT-In, FAQs on the Cyber Security Directions of 28.04.2022 cert-in.org.inMay 2022, 44 questions, linked from CERT-In’s own Directions page. It states of itself that it "is not a legal document and in no way whatsoever replaces, amends or alters" the IT Act or the CERT-In Rules, 2013, and that it is an evolving document.Relied on for Question 35, on whether logs may be held outside India, and question 43 on the NIC and NPL time-server hostnames.
CERT-In, Guidelines for Secure Application Design, Development, Implementation & Operations cert-in.org.inNamed in §8 of the 2025 audit policy guidelines as the secure-design reference, and the instrument behind §8(viii): an application developed without secure design and development practices should not be considered for assessment and audit, and the auditee is to be told so in writing with a copy to CERT-In.Relied on for The design-level expectations behind families 01 to 04, and the reason a design-stage failure is not something a retest can close.
Guidelines for Indian Government Websites and Apps (GIGW) 3.0 guidelines.india.gov.inGuideline 5.3.1, published by the National Informatics Centre with STQC and CERT-In at guidelines.india.gov.in. The cybersecurity chapter was formulated by CERT-In and, on GIGW’s own instruction, is read together with CERT-In guidance and advisories issued from time to time.Relied on for The requirement for a security audit clearance certificate before hosting in the production environment, issued by NIC, STQC, an STQC empanelled laboratory or a CERT-In empanelled laboratory. The reference set of ISO 27001, OWASP ASVS, the OWASP Top 10 and CIS benchmarks. The periodic-auditing attribute — at least once a year, or as and when any changes are done in the source code, whichever is earlier.
OWASP Top 10:2021 and OWASP API Security Top 10 2023 owasp.org/Top10/2021 · owasp.org/API-SecurityEditions named wherever cited, because each renumbers. The A01:2021 page is the source for the two figures this page carries: 318,487 occurrences in the contributed dataset, and 94 per cent of the applications in that dataset tested for some form of broken access control.Relied on for The category mapping table, and the API-list comparison.
OWASP ASVS 5.0.0, WSTG 4.2, MASVS v2.1.0 and MASTG v2.0.0 owasp.org/ASVS · mas.owasp.org/MASVSASVS 5.0.0 of May 2025 went from fourteen chapters to seventeen and renumbered every requirement from 4.0. MASVS v2.1.0 of January 2024 is the edition carrying eight control groups, MASVS-PRIVACY being the eighth, while v2.0.0 had seven. MASTG v2.0.0 of June 2026 renumbered its test identifiers, so a scope of work should name the MASTG version as well as the MASVS one.Relied on for The WSTG test identifiers and ASVS chapters on each family, and the mobile control groups.
Published specimen safe-to-host certificatesTwo certificates published on Government of India domains, read for anatomy only. The issuing firms are not named here.Relied on for The two observed forms of the validity note, and the fact that certificates differ in whether they name the hash algorithm alongside the hash value.

Sources last checked 22 September 2026. That date is load-bearing, because this page makes negative claims as well as positive ones — that CERT-In publishes no findings statistics, and no band-by-band rule saying which severity withholds a certificate. A negative claim is only as good as the date attached to it. If you are reading this well after that date, open the first two documents above before quoting either negative into a tender or a proposal.

Two notes on how the documents fit together. The empanelled-auditor guidelines are version 3.0 of May 2018 and the 2025 audit policy guidelines are the current instrument. Where the two speak to the same question — denial-of-service testing is the clearest example — this page gives both and says which is which, rather than quoting the older one as though it still stood alone. And the validity wording in the FAQ below on changing the application is quoted from the face of published certificates: it is a statement the issuing body makes, not a clause of GIGW or of CERT-In. What follows from a change to the application is set out in how long a safe-to-host certificate stays valid, and how to check a certificate you have been handed in how to verify a CERT-In audit certificate.

Frequently Asked Questions

Why do applications fail a safe-to-host audit?

For three kinds of reason. (1) Nine recurring finding families: broken access control and insecure direct object references, authentication and session defects, injection, unrestricted file upload, weak transport and header configuration, an internet-reachable administrative interface, verbose errors and information disclosure, known-vulnerable components, and secrets in client-side code. (2) Procedural failures that are not vulnerabilities at all — the wrong environment offered for testing, a scope narrower than the deployed service, missing test accounts, absent written testing approvals, or a release shipped mid-engagement. (3) Findings closed at the path named in the report rather than at the mechanism behind it, which does not survive a retest.

What are the most common vulnerabilities found in a CERT-In empanelled security audit?

CERT-In publishes no findings statistics, so no ranked table can be given with authority. Broken access control is the class most often found open in the CERT-In audits Tranquility Cybersecurity delivers with its CERT-In empanelled partners — a first-party observation — and the class automated tooling structurally cannot find. The public dataset points the same way: OWASP records A01:2021 with 318,487 occurrences, the most of any entry in that edition’s contributed dataset. (OWASP also reports that 94 per cent of the applications in that dataset were tested for some form of broken access control. That is a coverage figure — how widely it was looked for — and not a failure rate, so it should not be quoted as one.) After it: authentication defects in secondary flows, unrestricted file upload, an administrative console reachable from the internet, known-vulnerable components, and secrets in client-side code.

Our safe-to-host audit failed — what happens next?

Nothing is refused. Issue is deferred until the blocking findings are closed. In order: separate what blocks from what is carried. Identify which blocking findings belong to the hosting platform rather than to you, because §13.1.5 puts the server, its operating system, the hosting software and the backend database with the organisation that owns and operates the server. Put a named owner and a date on every row. Ask the auditor in writing what the follow-up audit will cover, how many rounds the engagement includes, what counts as a reopened finding, and whether closure evidence must come from production (§16.3(v) says the final report issues after the follow-up audit on production). Translate each finding from a path into a mechanism before writing code. Freeze and tag the remediated build and record its hash. Attack your own fix from an angle the report did not describe. Then build the closure register before booking the round. Do not renumber the findings, and do not mark your own rows closed.

What is a safe-to-host retest and how long does it take?

A retest is a smaller engagement with a narrower question: are the open findings actually closed. The instrument calls it a follow-up audit, and §9.3 and §13.1.1 put it inside the scope or the RFP from the outset rather than treating it as an extra. Its scope is the open findings plus whatever the fix touched, which is often wider. §16.3(v) expects it on the production environment, so agree early whether staging evidence will be accepted for any part of it. Elapsed time is driven by what was found — configuration fixes are hours to days, architectural fixes a release cycle, and a platform-owned finding moves at the platform owner’s pace. The variable you control is whether the first round was written at the mechanism, because a fix written at the reported path adds a further remediation and follow-up cycle.

Is the retest included in the audit fee, or do we pay again?

It depends on the engagement, and it is a question to settle before signing — in a named document. §14.1(ii) of the 2025 audit policy guidelines requires the agreed terms to be documented in an audit engagement letter, reviewed and signed by authorised representatives of both organisations and binding throughout. §9.3 puts follow-up audits — what this page calls retests — inside the scope or the RFP from the outset, and §13.1.1 says the same. The 2018 guidelines add the expectation-gap duty: the audit process, artefacts and deliverables are to be explained in detail beforehand and the deliverable structure agreed before commencement. So ask how many follow-up audits are included, what counts as a round, what happens if a finding reopens, and whether closure evidence must come from production under §16.3(v) — and get the answers into the engagement letter, not into an email thread.

How many findings is a normal safe-to-host report?

There is no normal, and a count on its own tells you little — it reflects the size of the scope, whether authenticated testing happened, whether the estate was swept beforehand, and how old the dependency tree is. Read the shape instead: how many findings block, and how many are carried with owners and dates. Be more concerned by a very short report than a long one. A thin report on a substantial application usually means the scope was narrow, the test accounts never arrived, or testing ran unauthenticated.

Can we get the certificate with open medium findings?

Ordinarily yes, where each carries a named owner and a closure date. §16.3(iii) of the 2025 audit policy guidelines requires the report to state closure timelines according to severity, which is the mechanism that lets a report carry open items at all. Where an item is accepted rather than fixed, §9.2 names who accepts it: risk treatment must be authorised and accepted by the head of the auditee organisation, and an exception on an application by the head of the organisation that owns it. A deferral with no date, no owner and no authorising office does not work, and the aggregate matters as well as the item. Critical and exploitable high findings are different: §16.3(v) puts the final report after closure and the follow-up audit on production, and in practice they are not issued over.

What is an audit observation closure report and what goes in it?

It is the register you prepare before a retest, one row per finding, and it is what lets an auditor close a finding on a reasoned statement rather than on your assurance. Eleven fields: the original identifier and title as the auditor wrote them, the severity as issued, the CWE and CVE as issued, the affected components (including siblings you found yourself), a remediation summary describing the mechanism changed, the evidence artefact and its source system, the retest method you propose, the environment the fix is deployed in, the result and date (left blank for the auditor), residual risk where the fix is interim, and a named owner.

What if the same finding comes back at the second retest?

It stops being a finding about the defect and becomes a finding about your closure process, which is worse. Two things cause it: the fix was again written at a path and the auditor found a sibling endpoint or a different encoding, or an interim control was presented as a structural fix. The way out of the first is one enforcement point plus a test that fails when something bypasses it. The way out of the second is to declare interim controls as interim, with a dated plan attached.

Our application is a mobile app — what fails most often?

The API behind it fails for the same nine reasons a web application does, and the client adds its own set: sensitive data in local storage or logs, components exported without need and deep links that act without re-establishing who is asking, WebView configuration that exposes a native bridge or ignores certificate errors, plaintext permitted by the network security configuration, release builds still debuggable, and credentials extractable from the binary. Cite the OWASP Mobile Application Security Verification Standard for a mobile scope, naming the edition — MASVS v2.1.0 of January 2024 is the one with eight control groups — and the MASTG version supplying the test procedures, currently v2.0.0 of June 2026. The point teams miss most is artefact identity: the build tested and the build submitted must be the same file.

Can a WAF close a finding?

It reduces exposure and does not close a code defect, because a retest will try to reach the application around the filter — a different encoding, a different content type, or a direct request to the origin. Where a filter is the only thing between an injection flaw and the database, an honest report records the flaw as open with a filter deployed.

Does the OWASP Top 10 define what is tested in a safe-to-host audit?

No, and CERT-In says so in terms. §8 of the Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, 25 July 2025) states that limited lists such as the OWASP Top 10, SANS Top 25 and similar should not be considered as standards or references for audits. The standards it names instead are ISO/IEC standards, CERT-In’s Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM 3, the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard, the OWASP Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model. GIGW 3.0 does name the Top 10, alongside ISO 27001, ASVS and CIS benchmarks, and it remains a useful shared vocabulary — the mapping is clean for broken access control, injection and vulnerable components, and strained for file upload, information disclosure and embedded secrets. Where it runs out, cite WSTG test identifiers for what was done and ASVS chapters for what was verified, naming the version of each: ASVS 5.0.0 of May 2025 renumbered every requirement from 4.0. Where the service is an API, the web list is the wrong list.

Does a failed audit get reported to CERT-In?

There is no pass-or-fail notice about your organisation — but the report itself does reach CERT-In, per engagement, and you are entitled to be told so before the work starts. Clause 3.2.2 of the Empanelment Terms and Conditions (version 7.2, April 2024) and §10.6 of the 2025 audit policy guidelines make it mandatory for the auditing organisation to share the audit report and audit metadata with CERT-In within five days of completion of the audit, in the format CERT-In prescribes. Clause 3.2.1 requires details of every audit with auditee details. Clause 3.2.2 also requires all critical vulnerabilities pointed out during the audit but not fixed by the auditee even during follow-up audits to be reported to CERT-In, with auditee details, on the same five-day clock — which is the closest thing to a failure being reported that exists. §13.2.1(iii) requires your auditor to tell you about that duty before the assignment begins, and clause 3.1.7 records that empanelled organisations provide reports and data to CERT-In without the auditee’s explicit permission. Three further duties run alongside it: §10.1(ii) requires in-scope assets the auditor could not reach to be named in the report and brought to CERT-In’s notice, §15.2.2(i) requires a discovered breach to be reported immediately to the auditee and to CERT-In, and the 2018 guidelines add a periodic, aggregate quarterly report covering the number of audits, the sector and high-level findings. Separately, and as an obligation on you rather than on the auditor, where the entity falls within the CERT-In Directions of 28 April 2022, Annexure I incidents must be reported within six hours of being noticed.

What happens to the certificate when we change the application?

Validity is a statement the issuing body makes on the face of the certificate, and the wording varies by issuer, so read your own before planning around it. Two certificates published on Government of India domains show the range: one is valid “till no additional changes in the Hash value or dynamic contents carried out or one year from the date of issue, whichever is earlier”, while the other states that “the maximum validity of the certificate is One Year from the date of issue” and holds its opinion only for the period during which no changes are made in the source of the tested application, any change requiring a re-audit of the new version. Neither uses the phrase “major change”. That phrase belongs to a different question — when you must audit — and it is defined, at §13.1.2 of the Comprehensive Cyber Security Audit Policy Guidelines: changes are classified as Minor (low-risk, non-critical) or Major (high-risk, impactful to security, expressly including configuration adjustments that affect sensitive data or critical infrastructure), and a major change must undergo a cyber security audit before implementation. So it is classified by risk, not by size. What your department should write down is how it will apply that definition and evidence the classification — not a competing definition of its own.

Does Tranquility Cybersecurity deliver CERT-In audits, including safe-to-host audits?

Yes. We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. A safe-to-host audit is one of them.

Written By Expert Auditors

Surendra Pal SinghChief Information Security Officer & Data Protection OfficerCISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi ChauhanLead AuditorISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Last reviewed: September 2026 • Content verified by certified lead auditors

Keep Exploring

Why Applications Fail a Safe-to-Host Audit

Key Takeaways

The nine findings that most often block a safe-to-host certificate

Is there a pass mark for a safe-to-host audit? No — there is a statement.

Which findings block a safe-to-host certificate, by severity

Will the certificate be issued with this still open?

What does an audit observation contain?

Where the OWASP mapping is real, and where it is not

How do the nine families map if the service is an API?

The five findings an attacker finds by attacking: access control, authentication, injection, upload, transport

Broken access control and insecure direct object references

Weak authentication, password reset and session handling

SQL injection, command injection and cross-site scripting

Unrestricted file upload

Missing security headers and weak TLS configuration

The four findings nobody has to attack to find: exposed admin, information disclosure, outdated components, leaked secrets

Internet-reachable admin console or management interface

Stack traces, debug pages and information disclosure

Known-vulnerable libraries, runtimes and base images

Hard-coded API keys and credentials in client code

If the application is a mobile app

Sensitive data in local storage

Exported components and deep links

WebView configuration

Transport and certificate validation

Debuggable or backup-enabled builds

Secrets in the binary

The tested build is not the submitted build

A first report, a suppression, and a second retest

What happens at a safe-to-host retest, which the instrument calls a follow-up audit

The closure register, field by field

Why safe-to-host audits stall for reasons that are not vulnerabilities

Findings that come from the Directions, not from OWASP

The pre-audit pass you can run on yourself

The week after the report lands, in order

Who tests, who signs, who fixes

We deliver CERT-In audits

The primary sources, named and linked

Frequently Asked Questions

Written By Expert Auditors

Related Reading

How to Get a Safe-to-Host Certificate

What a Safe-to-Host Certificate Is

GIGW Compliance Before Go-Live

How Long a Safe-to-Host Certificate Lasts

VAPT / Penetration Testing

Rules of Engagement for an Empanelled Auditor

Get in touch

Send us your requirement.

Go deeper.

SOC 2 Services & Consulting

The SOC 2 Cost Guide

The SOC 2 Knowledge Hub