Secure Coding Practices in Banks: OWASP, SAST and SDLC Gates

Secure coding practices in banks are the controls that decide whether a core banking module, an internet banking portal or a payment API ships with an exploitable defect or without one. A bank can buy the best perimeter devices available and still lose customer data because one developer concatenated user input into an SQL string. For IIBF IT Security candidates this is a scoring area: the examiner rarely asks you to write code, but very often asks which control belongs at which stage of the software development life cycle, what a particular OWASP category means in a banking context, and who owns the sign-off before a release moves to production. This article walks through the syllabus view of application security — OWASP mapping, validation and query handling, session and secrets discipline, automated testing gates in the pipeline, and review of third-party components — in the order an exam question is likely to travel.

🔐 Why Secure Coding Is a Regulatory Expectation, Not a Developer Preference

Indian banks do not treat application security as an internal engineering nicety. RBI's Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices requires regulated entities to follow a documented secure software development life cycle, to test applications before deployment and to keep the development, test and production environments separated with controlled migration between them. The board-approved IT policy has to name the owner of these controls, and the IS audit function has to be able to evidence that the gates actually ran, not merely that a policy exists. That evidential burden is why banks insist on artefacts — scan reports, review sign-offs, approval records — rather than verbal assurance from a project manager.

The same expectation flows down to outsourced development, which is how most Indian banks build channel applications. If a vendor writes the code, the bank still owns the risk, so contracts typically carry a right to audit, a requirement to hand over scan evidence, and an obligation to remediate findings within agreed timelines. You can see how this connects to the wider control set in the study notes on controls in software development and maintenance, which is the chapter examiners draw most of these questions from.

📌 Remember: Outsourcing the coding never outsources the accountability. The bank remains answerable to the regulator and to the customer for a defect written by a vendor's developer.

Practically, this means secure coding sits inside governance, not beside it: requirement documents carry security requirements, design reviews carry threat modelling, and no build reaches user acceptance testing without passing the defined gates. Read this alongside patch management in banking systems, because a clean codebase running on an unpatched application server is still a vulnerable system.

🧩 OWASP Top 10 Mapped to Real Banking Applications

The OWASP Top 10 is the reference list most banks and most IIBF questions use. Rather than memorising the list mechanically, map each category to something a bank actually runs — that is how the scenario questions are framed.

Broken access control is the category that hurts banks most. If a retail banking portal accepts an account number in the URL and displays the statement without checking that the logged-in customer owns that account, any customer can read another customer's data. This is the classic insecure direct object reference, and it is a logic flaw no scanner reliably finds. Injection covers SQL, OS command and LDAP injection — the payment reconciliation screen that builds a query from a search box is the standard example. Cryptographic failures cover card data or customer identifiers stored or transmitted without adequate protection, or protected with an algorithm the bank's own standard has already retired.

Security misconfiguration shows up as verbose error pages leaking stack traces and database names, default administrative credentials left on a middleware console, or debug endpoints reachable from the internet. Vulnerable and outdated components is the open-source library problem discussed later. Identification and authentication failures include weak session expiry and predictable password reset tokens. Server-side request forgery matters wherever an application fetches a URL supplied by a user, such as a document-upload-by-link feature.

⚠️ Common Mistake: Treating the OWASP Top 10 as a fixed, permanent list. OWASP revises the categories periodically and renames or merges them — quote the category behaviour in the exam, and check the current edition on owasp.org before citing a rank number.

The chapter on software security covers these categories in the language the question paper uses, and the wider threat context appears in security operations centre in banks, since the SOC is what detects exploitation of a defect you failed to prevent.

🛡️ Input Validation, Parameterised Queries and Output Encoding

Three defensive techniques carry most of the weight in secure coding, and the exam expects you to distinguish them clearly.

Input validation means checking every input against what it is supposed to be before the application uses it — length, data type, format, and permitted character set. The correct model is allow-listing (accept only what matches the expected pattern) rather than deny-listing (block a list of known bad strings), because attackers keep inventing encodings the deny-list has never seen. An IFSC field should accept eleven characters in the defined pattern and nothing else. Critically, validation must happen on the server. Client-side JavaScript validation is a usability feature only — an attacker sends the request directly and never runs your script.

Parameterised queries (prepared statements) are the real defence against SQL injection. The application sends the query structure and the data separately, so the database treats a supplied value as a value and never as executable SQL. Escaping input by hand and then concatenating is a weaker, error-prone substitute; stored procedures help only if they too avoid dynamic SQL built from parameters. Where dynamic table or column names are genuinely unavoidable, the value must be checked against a fixed allow-list in code.

Output encoding defends the other direction. Data that was safe to store may be dangerous to display, so anything rendered back into a web page must be encoded for the context it lands in — HTML body, HTML attribute, JavaScript or URL. This is what stops stored cross-site scripting, where a payload saved in a beneficiary nickname executes in a bank officer's browser days later.

💡 Exam Tip: Validate input, parameterise queries, encode output. If a question describes a defect, decide which of these three was missing — that identification is usually the whole answer.

🔑 Session Handling, Error Handling and Secrets Management

Once a customer authenticates, the session identifier is effectively the credential, so it deserves credential-grade protection. Session tokens must be generated by a cryptographically secure random generator, never derived from a customer ID, mobile number or timestamp. A fresh session identifier must be issued at the moment of successful login — reusing the pre-login token is what enables session fixation. Cookies carrying the session should be marked Secure so they travel only over TLS, HttpOnly so scripts cannot read them, and with an appropriate SameSite attribute to blunt cross-site request forgery. Banking applications additionally enforce short idle timeouts, an absolute session lifetime, and genuine server-side invalidation on logout, because deleting the cookie in the browser while the server still honours the token achieves nothing.

Error handling is the quiet companion control. The user should see a generic failure message and a reference number; the detailed stack trace, SQL statement and file path belong in a protected log. Equally, authentication errors must not reveal whether the customer identifier exists — an "invalid user" versus "invalid password" distinction hands an attacker a free account enumeration tool. Logs themselves must never capture passwords, full card numbers, OTPs or session tokens.

Secrets management is where audits most often find issues. Database passwords, API keys, encryption keys and service account credentials must never sit in source code, configuration files committed to the repository, or scripts on a shared drive. They belong in a vault or a hardware security module, injected at runtime, rotated on a defined cycle and revoked immediately when a developer leaves. A credential pushed to a repository is compromised even after the commit is deleted, because the history retains it. The software security control chapter treats these as standard application controls, and the same discipline underpins card and payment work such as prepaid payment instruments in India.

⚙️ SAST, DAST, SCA and the Secure SDLC Gates

Modern banks automate the checks so they run on every build rather than once before go-live. Each technique sees a different slice of the problem, which is exactly what the comparison questions test.

The gates are only meaningful if a failure actually blocks the build. A common audit finding is that a bank has bought a scanner, wired it into the pipeline, and then configured every finding as a warning — so nothing ever stops. Mature practice defines severity thresholds: critical and high findings break the build, medium findings need a dated remediation plan, and any exception is a documented risk acceptance approved by a named authority with an expiry date, not a permanent waiver. Scan results should also feed the same tracking system used for infrastructure findings so that the bank has one consolidated view of technical risk, as covered under security standards and best practices.

🔎 Code Review and Third-Party Library Risk

Automation finds patterns; humans find intent. Peer code review remains mandatory for banking applications precisely because the highest-impact defects are logical. A scanner cannot tell you that a transfer function checks the daily limit before applying the exchange rate rather than after, or that a maker-checker workflow can be bypassed by re-submitting an approved request identifier. Effective review in a bank has a few non-negotiables: the author never approves their own change, security-sensitive modules such as authentication, authorisation, payment posting and cryptography get a second reviewer, and the reviewer works from a checklist mapped to the bank's own coding standard rather than from instinct. The review record is itself an audit artefact.

Third-party and open-source components deserve separate attention because most of a modern banking application, by line count, is code the bank did not write. A usable control set is narrow: pull dependencies only from an internal approved repository rather than directly from the public internet, maintain a software bill of materials so you can answer "are we exposed?" within hours of a disclosure, pin versions so builds are reproducible, and re-scan continuously — a library that was clean at release becomes vulnerable the day a new advisory is published. Abandoned projects with no active maintainer are a risk even when no vulnerability is currently known, because there will be nobody to publish a fix.

This is the point where application security meets vendor governance, so study it together with supply chain security risk in banks and browse the full set of notes on the IT Security tag hub. For the regulatory wording itself, the current master directions are published on the RBI website.

🧠 Practice MCQs: Secure Coding and Application Security

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

📚 Conclusion: Turning This Into Marks

Secure coding is examined as a chain, not a list. Requirements carry security acceptance criteria, design carries threat modelling, development follows the bank's coding standard, the pipeline enforces automated gates, humans review the logic that automation cannot judge, and release is blocked until findings are closed or formally accepted. If you can recite that chain and place any given control on it — parameterised queries in development, DAST in test, penetration testing before go-live, SCA continuously — most scenario questions in this module answer themselves. Pair this with the network-side controls in network controls for a complete view of the defence-in-depth chapter, then test yourself. Work through the full IT Security question bank in the CAIIB and certification course library and take a timed chapter test at iibf.store mock tests before your exam date.