Security in Mind

Introduction

We are rapidly accelerating into a digital-first world, where traditional cash transactions are increasingly replaced by eWallets, food is ordered through QR code scans and shopping is conducted primarily through e-commerce platforms (e.g. Shopee or Lazada).

However, cybersecurity threats remain persistent.

• There are ongoing reports of users unknowingly clicking on malicious links delivered via WhatsApp, emails or dynamic QR codes, which redirect them to phishing websites.
• On vulnerable devices or outdated browsers, these interactions can lead to unauthorized access, session hijacking or even malware installation capable of acting on the user’s behalf.

Unlike earlier days of mobile development, platforms like Google Play Store now enforce stricter app security policies, delisting apps that fail to meet modern security standards.

• As developers, the responsibility to build secure applications is not purely technical, but it also carries a social obligation, especially in an era where real-life cybercrime (e.g., attackers breaching critical networks or stealing credentials) no longer feels fictional.

Identify Vulnerabilities

Once core functionality is complete, developers should shift focus toward identifying and addressing potential security vulnerabilities.

• Following the Pareto Principle (80/20 rule), the most impactful improvements often come from addressing the top few critical issues.
• The OWASP Top Ten is a globally recognized awareness document that outlines the most common and critical security risks in web applications, based on data from real-world attacks.

Key categories include:

• Broken access control - Inadequate permission checks, allowing users to escalate privileges or access unauthorized data.
• Cryptographic failures - Often involves weak encryption, missing HTTPS or improper handling of sensitive data in transit or at rest.
• Injection - Attacks such as SQL or command injection, where untrusted input is executed by the server, leading to unauthorized data access or system compromise.
• Vulnerable and outdated components - Use of libraries or dependencies with known security flaws that have not been patched.
• Identification and authentication failures - Poor password enforcement, broken session handling, or missing multi-factor authentication (MFA).

While the OWASP Top Ten offers a high-level overview of common risks, the OWASP Application Security Verification Standard (ASVS) provides a more detailed checklist of security controls and technical verification requirements for secure design and implementation.

Practical Measures Against Real-World Threats

The most effective defence against cybersecurity is to design securely from the start, rather than patching vulnerabilities retroactively.

• At each stage of development, proactively assess security risks, especially around input handling, authentication and session management, dependency management and rendering of dynamic content.

For most secure websites, this begins with HTTPS, which relies on a TLS (Transport Layer Security) certificate to encrypt data between client and server.

• For example, if a user connects to a public Wi-Fi network and visits a non-HTTPS site, attackers on the same network could easily intercept credentials, session cookies, or inject malicious content via a man-in-the-middle (MitM) attack.
• Even if HTTPS is enabled, ensure the Strict-Transport-Security (HSTS) header is also set. This crucial step helps prevent SSL Stripping Attacks by instructing browsers to exclusively connect to your site via a secure (HTTPS) connection, thereby eliminating the risk of a downgrade to unencrypted HTTP.

Many modern apps display rich HTML content from user input, Content Management Systems (CMS) platforms like Blogger, or real-time databases like Firestore.

• Without proper sanitization, these can become injection vectors, particularly for Cross-Site Scripting (XSS).
• XSS occurs when untrusted input is inserted into the Document Object Model (DOM) without proper validation and encoding. If an attacker successfully injects a <script> tag, it may lead to severe consequences, including session hijacking, credential theft, UI defacement, phishing redirection and unauthorized actions via stolen tokens.
• To mitigate this, a Content Security Policy (CSP) should be implemented, alongside a two-layer defence strategy:
• Input Validation - Accept only data in expected formats and reject any malformed or suspicious input at the earliest possible point.
• Output Sanitization - Use a robust library like DOMPurify to meticulously remove harmful code before rendering user-generated or external content in the browser.
• Adopting the zero trust principle, it is a fundamental security imperative to never trust user input. Critically, this extends to not blindly trusting backend responses, even from your own systems. A compromised backend or a vulnerable third-party integration can become an insidious path for malicious payloads to reach your frontend.

In the real world, while a well-configured CSP is a fantastic layer of defense, business and development teams often weigh the high cost of implementation and the risk of breaking their site against the protection it offers, especially when it involves third-party scripts.

• They may decide to accept certain risks and rely on other security measures like input sanitization, framework protection, automated monitoring for malicious activity, and sandboxing.
• Similarly, a weakened CSP that allows inline scripting, though providing some peripheral benefit, should not give the false impression of the full protection that a robust CSP offers.

Another common area of confusion is the distinction between authentication and access control.

• Authentication confirms user identity (e.g., via a login process), while access control determines what resources or actions the user is allowed (e.g., distinguish between an "admin" and a "viewer" role).
• Best practices for these areas include
• Implement authentication on the server side to prevent client-side manipulation.
• Enforce strong password policies that mandate complexity, length and regular changes.
• Apply rate limiting and account lockout to effectively mitigate brute-force attacks.
• For sensitive operations, consider implementing session tokens, SecureTAC (transaction approval codes) or multi-factor authentication (MFA).
• Once an attacker gains session access, they may exploit internal privileges or pivot to more sensitive parts of the system.

Even with well-structured logic, vulnerabilities can still emerge through outdated third-party libraries or insecure mobile operating systems.

• Regularly run npm audit (or a more advanced tool like Synk) to detect known security issues in your dependencies.
• Remove unused packages and keep libraries consistently up to date.
• As observed in financial applications, many companies have abandoned legacy mobile apps and now enforce higher minimum OS requirements to circumvent platform-level exploits.

As a final practical tip, use security testing tools throughout the development lifecycle.

• OWASP ZAP (Zed Attack Proxy) is an excellent beginner-friendly tool for simulating common web application security attacks, including Cross-Site Scripting (XSS), SQL injection, and Broken Access Control. It helps developers and security testers identify vulnerabilities early in the development cycle.
• After installing OWASP ZAP, launch the app, and enter the target URL (e.g., your local or staging environment) into the “URL to attack” field. Click “Attack” to run an automated scan.
• ZAP will crawl your site, simulate various attack patterns, and present a list of discovered vulnerabilities sorted by risk level (High, Medium, Low, Informational).
• Use SecurityHeaders.com for quick feedback on your HTTP security headers, or Mozilla Observatory for a more comprehensive review that includes TLS analysis, header configuration, and third-party scans.
• Complement these with Google CSP Evaluator, which analyzes your Content Security Policy (CSP) to ensure it is effectively configured to prevent script injection (XSS) and clickjacking threats by detecting unsafe patterns like 'unsafe-inline' or overly permissive script-src rules.

Security Headers

Security headers serve as explicit, server-sent directives to the user's web browser, instructing it to enforce specific security policies that often supersede the browser's default, more permissive configurations.

• This proactive approach is fundamental to a defense-in-depth strategy, where multiple layers of security are deployed to mitigate risks.
• By configuring these headers, web developers establish a crucial client-side security perimeter.
• For instance, X-Frame-Options (or its modern equivalent within Content Security Policy) can prevent clickjacking by disallowing your site from being embedded in a malicious <iframe>.
• Similarly, X-Content-Type-Options: nosniff stops browsers from MIME-sniffing a response's content type, thereby preventing scenarios where a malicious script disguised as an image might be executed.
• These headers empower the website owner to dictate how the browser should interpret and render content, significantly tightening security permissions beyond what a browser would, by default, assume as safe.

However, a critical consideration is the varying levels of browser support for these evolving security directives.

• When a legacy browser encounters a security header it does not recognize or fully implement, it typically ignores it.
• This means the intended security enhancement is rendered null for that particular user.
• Take the Permissions-Policy (formerly Feature-Policy) header as a prime example. This header allows a website to selectively enable or disable powerful browser APIs (e.g., geolocation, camera, microphone) for the main document and its embedded iframes. If a user accesses your site with an older browser that predates Permissions-Policy support, that browser will simply disregard the header. Consequently, malicious scripts or compromised third-party content, which would have been constrained by Permissions-Policy on a modern browser, might retain unauthorized access to these sensitive APIs, exposing the user to potential privacy breaches or attacks.

In essence, while security headers are indispensable tools for fortifying web applications against contemporary threats by instructing browsers to adopt stricter security postures, their effectiveness is inherently tied to browser compliance.

• Developers must strategically balance the implementation of the cutting-edge security features with the realities of the browser landscape, understanding that newer headers will only benefit users on compatible, up-to-date browsers.

Summary

Secure application development requires anticipating and preparing for failure, whether it comes from malicious user input, third-party integrations, outdated libraries, or insecure platforms.

• A resilient architecture follows the principle of Defence in Depth, implementing multiple layers of security at every level of the stack, including input validation, output sanitization, HTTPS with TLS, CSP headers, authentication and access controls, secure dependencies and runtime protection.
• This layered approach ensures that even if one control is bypassed, others will still mitigate the risk, reducing the likelihood and impact of successful attacks, aligning with breach control.

Ultimately, building securely is more than just writing code.

• It is a long-term responsibility, especially when you are handling sensitive user data, financial transactions, or user identities.