Application Development Security Best Practices: Protect Your App Against Critical Risks

The frequency of cyberattacks is rising worldwide, and so is their effectiveness, even though cybersecurity strategies and tools are becoming increasingly sophisticated.

Anyone can be a target—a bank, an energy provider, a governmental organization, or an e-commerce company. Although hackers mainly try to penetrate internal systems, apps serving customers can also be attacked and robbed of sensitive data. And that, of course, implies severe financial and reputation consequences.

Although the risk exists, withdrawing from digital solutions clearly is not an option. With the right set of risk mitigation practices, you can prevent the attacks and minimize the severity of their impact. One thing is certain – the earlier you start, the better.

Adopting the risk-conscious approach at the earliest stage of the software development cycle will allow you to create architecture that facilitates implementing good mobile and web application security practices, whether you are working in-house or using external bespoke software development services.

Today, we break down the key principles in data management, software development and maintenance that will keep your application safe. Dive into the most common security vulnerabilities and the specifics of particular cyberattacks and learn how to protect yourself and your users effectively.

Average Industry-Exposure VS Security Score
Average Industry-Exposure vs Security Score

Common security vulnerabilities in application development

The best way to start implementing security best practices? Know your enemy. Understand the general and platform-specific weaknesses that your application might present and target them. Regarding secure web applications, here are the most common threats they should be prepared for.

SQL injection

SQL Injection (SQLi) happens when an attacker manipulates an application’s SQL database query by inserting malicious code through user input fields, gaining unauthorized access to sensitive data.

Attack Scenario: Imagine a retail website where users enter their username and password. An attacker enters a code instead of a password, bypassing authentication to view all user data.

Who’s Most at Risk? Websites and apps that rely heavily on SQL databases, like e-commerce, finance, and social media platforms.

SQL Injection Attack
SQL Injection Attack Explained

Cross-site scripting (XSS)

Cross-site scripting (XSS) is a vulnerability that allows attackers to inject malicious scripts into web pages viewed by others. This script can steal user data or impersonate the user, gaining unauthorized access to their accounts and stealing critical information.

Attack Scenario: An attacker leaves a script as a comment on a blog. When other users view the comment, their browsers execute the script, which silently steals their session cookies and enables the hacker to hijack their accounts.

Who’s Most at Risk? Websites with user-generated content, like forums, blogs, social media sites, and customer support portals.

Core site scripting
Core site scripting process

Many security risks are common to both web and mobile applications, but some threats are specific to the latter. This is mainly due to data and code being stored on the device and access to system resources. As a result, the following attack scenarios are the most prevalent for mobile applications.

Reverse engineering

Reverse engineering involves analyzing an app’s code to access sensitive information, making unprotected data vulnerable to attackers.

Attack Scenario: An attacker downloads a mobile banking app, decompiles its code, and discovers unencrypted user credentials stored locally. With this information, they gain unauthorized access to customer accounts and sensitive data.

Who’s Most at Risk?: Financial, healthcare, and other applications managing sensitive customer data without encryption or code obfuscation are especially vulnerable.

Malware

Malware is malicious software that infiltrates devices, often disguised as legitimate apps, to steal or manipulate user data.

Attack Scenario: A user downloads a seemingly harmless app infected with malware. The malware accesses stored credentials and transaction data from a mobile banking app, allowing the attacker to intercept user information and initiate unauthorized transactions.

Who’s Most at Risk?: Mobile banking, financial services, and healthcare apps, particularly those without malware detection and data encryption, face high risks of data breaches through malware.

Insecure data storage

When sensitive data (like user credentials or financial information) is stored without proper encryption or security, it is relatively easy for attackers to access if they gain entry to the system. In an instant, the company can lose reputation it has been working on for years and expose itselft to

Attack Scenario: A mobile banking app stores customer data, including passwords, unencrypted. If a hacker gains access to the app’s backend, they can view and steal this data directly.

Who’s Most at Risk? Mobile apps, healthcare, financial apps, or any software handling sensitive customer data without secure storage practices.

Security in the software development lifecycle (SDLC)

The popular saying goes, ” Forewarned is forearmed.” This applies perfectly to security practices in the software development lifecycle. The earlier you identify potential threats and vulnerabilities in your development process, the more effective you will be in preventing successful attacks. Understanding which types of attacks you could be a subject to and their typical scenarios will help you steer your security preventive measures in the right direction.

Before we move to the good practices, here is a checklist of essential aspects to define at the start of your development lifecycle:

  1. Which type of vulnerabilities are prevalent in the case of your industry/type of processed data/technology/software architecture?
  2. What kind of attack could cause the most serious consequences to your company, both financial and reputation-wise?
  3. Which tech stack can minimize the risk of security breaches? Can you choose a tech stack that both minimizes security risks and provides you with best performance, scalability and flexibility?

Balance between functionality and security

Let’s consider a scenario in which we’re developing a social media app that has a comments section and interactive engagement features, like likes, shares, and a real-time chat. These features heavily rely on user-generated content (UGC) to drive engagement, which is essential for our app’s key performance indicators (KPIs). Whether your app’s web or mobile, you will not be able to enhance interactivity and responsiveness without JavaScript. However, using it with UGC introduces potential XSS risks if any user-generated scripts are allowed to execute.

With that in mind, using input sanitization and encoding should be your focus from the scratch to prevent the probability of XSS. Next step is to configure a robust content security policy that will only allow JavaScript from trusted sources and block scripts from untrusted origins. Disabling inline JavaScript execution will further protect you against such breaches.

Supply chain attacks in application development

In many cases, the compromised security is imprinted into software at the very early stage through a compromised build process. Once it happens to third-party software supporting numerous organizations accross the supply chains, the consequences might be devastating.

That was the case of the SolarWinds Supply Chain attack, which affected high profile high-profile organizations, including several U.S. government agencies (e.g., the Department of Homeland Security, Treasury) and private companies such as Microsoft.

Attackers managed to insert malicious code into the Orion software, a widely-used network management platform. The compromised version was distributed to SolarWinds customers, allowing attackers to infiltrate several government agencies and corporations.

If your app is deployed across supply chain as Orion, these good practices are essential for your and your customers’ safety:

  • Implement Code Signing and Verification: Sign all builds with digital certificates and automate integrity checks throughout the release pipeline.
  • Secure CI/CD Pipeline: Limit permissions, enforce encrypted connections, and actively monitor for unusual activity.
  • Enforce Source Code Management Policies: Conduct mandatory code reviews, use static analysis, and scan dependencies for vulnerabilities.
  • Use Reproducible Builds: Ensure builds are reproducible to detect any tampering by comparing output with trusted versions.
  • Conduct Regular Audits and Red Team Exercises: Perform periodic security audits and red team tests to identify and mitigate vulnerabilities.

To maintain highest security, don’t limit your effort to the technical teams. Secure-by-design efforts should be in corporate financial reports, regularly updating the board of directors, and empowering senior leaders to drive security improvements. By integrating security goals into business processes, offering meaningful incentives, and creating dedicated security councils, organizations ensure that customer security is a core business priority, not just a technical concern.

Data encryption and secure communication

Encrypting sensitive user data both in transit and at rest is essential to its safety, To provide yourself with full security coverage, you should combine the SSL/TSL protocols which protect the data in transit and end-to-end encryption protecting both circulating and stored data.

SSL/TLS (Secure Sockets Layer/Transport Layer Security) establishes a secure, encrypted connection between a user’s browser and a server. End to end encryption, typical to messaging apps and cloud storage (but not only) secures data exchange between devices. Data is encrypted on the sender’s device, sent over the network, and only decrypted by the intended recipient.

SSL TLS Protocols
SSL/TLS Protocols

SSL/TLS Protocols

  • What does it protect you from?
    • Eavesdropping: Prevents attackers from intercepting and reading data in transit, protecting sensitive information like login credentials.
    • Man-in-the-Middle (MITM) Attacks: The protocol verifies the identity of servers, preventing attackers from impersonating a site.
    • Data Integrity: SSL/TLS ensures that data sent between clients and servers is not altered during transmission.
  • What should you remember?
    • Always use up-to-date SSL/TLS versions (currently TLS 1.2 or 1.3) and avoid outdated protocols.
    • Regularly renew certificates to maintain secure, trusted connections.
    • Implement HSTS (HTTP Strict Transport Security) to enforce HTTPS, protecting against protocol downgrade attacks.

End-to-End Encryption (E2EE)

  • What does it protect you from?
    • Unauthorized Access: Prevents intermediaries, including service providers, from accessing data in transit or storage.
    • Data Interception: If data is intercepted, it remains encrypted and unreadable to unauthorized parties.
    • Data Tampering: E2EE often includes digital signatures, which verify data integrity, ensuring it hasn’t been modified in transit.
  • What should you remember?
    • Ensure that all parties use secure key exchange methods, such as Diffie-Hellman or RSA, to avoid interception.
    • Be aware of metadata exposure, as E2EE often doesn’t protect against it.
    • Use reputable services that implement strong E2EE protocols and regularly update them for security compliance.

According to Veeam 2024 Ransomware Trends Report, 96% of ransomware attacks in 2023 targeted backup repositories. Attackers often try to encrypt or delete backups to maximize the victim’s reliance on paying the ransom. Keeping backups in isolated and safe storage environments, like offline (air-gapped) systems or secure cloud backups, prevents ransomware from spreading to backup files.

Encrypting sensitive data before storing it (whether on-premises or in the cloud) makes it less valuable to attackers. If an attacker manages to access encrypted data, they would still need the decryption key to make sense of the information, which can make the attack less profitable or impactful.

Sometimes even end-to-end encryption is not enough. 2019 Whatsapp breach case can serve as an example. Although they were encrypted, the Pegasus spyware stole the data of over 1400 Whatsapp users, including activists and journalists. Note, however, that Pegasus is a powerful tool that most of the hackers will not have access to. In most cases, strong and regularily updated encryption protocols are

Authentication and authorization

One of the most common scenarios leading to successful security breaches in client-side apps is the exploitation of vulnerabilities in user authentication. For applications handling sensitive data, such security measures are essential for protection, making cybercriminals unable to gain unauthorized access. A significant portion of modern apps uses multiple methods simultaneously, for example, combining account access security across different devices with social media authorization.

OAuth enables access to data without sharing credentials, reducing the risk of attacks. For instance, a user can log into Spotify via their Meta account, authorizing their login and granting permission to share information with Spotify. This is a great convenience for both the user and the application provider while also serving as a protective measure.

Comparison of user authentication practice
User authentication practices

Multi-Factor Authentication (MFA)

  • How does it work?
    MFA requires users to provide multiple forms of verification, typically combining something they know (like a password) with something they have (like a smartphone app or hardware token).
  • When is it suitable?
    It is suitable for any application or service that handles sensitive data, requires secure access, or is targeted by malicious actors.
  • Strong side?
    MFA significantly enhances security by adding additional layers of protection, making it much harder for unauthorized users to gain access.
  • Weak side?
    Users may find MFA cumbersome, leading to potential frustration or reduced user experience, especially if recovery options are not user-friendly.

OAuth

  • How does it work?
    OAuth is an authorization framework that allows third-party applications to obtain limited access to a user’s resources without sharing their credentials, typically using tokens.
  • When is it suitable?
    It is suitable for applications that need to interact with other services on behalf of the user, such as social media logins or API integrations.
  • Strong side?
    OAuth enhances security by allowing users to grant access to their data without sharing their passwords, reducing the risk of credential theft.
  • Weak side?
    If not implemented correctly, OAuth can introduce vulnerabilities, such as insufficient token expiration or improper token handling, leading to unauthorized access.

If your application serves internal enterprise purposes, the next crucial aspect you should take care of is Role-Based Access Control (RBAC). This model allows you to restrict the resources and areas the user has access to based on their role. Once you define your resources and roles, you can design a permissions structure that ensures the highest security.

Role-based access control
Role-based access control

Imagine, for instance, setting up system permissions for a middle-sized e-commerce company. The exemplary RBAC matrix in such a scenario could adopt a similar shape:

ResourceCustomer SupportSales ManagerInventory ManagerFinanceMarketingIT AdminExec / Analyst
Customer DataRead/WriteFull AccessNo AccessNo AccessLimitedFullRead-Only
Order ManagementReadFull AccessRead/WriteRead-OnlyNo AccessFullRead-Only
Payment ProcessingNo AccessNo AccessNo AccessFullNo AccessFullRead-Only
AnalyticsReadRead-OnlyNo AccessReadRead-OnlyFullFull
CMSNo AccessRead-OnlyRead/WriteNo AccessFullFullNo Access
Marketing ToolsNo AccessNo AccessNo AccessNo AccessFullFullRead-Only
Example of setting up system permissions for a middle-sized e-commerce company: RBAC matrix

Third-party libraries and dependencies: how to lower the costs wile staying safe?

Third-party libraries and open-source dependencies are inherently associated with the risk of security breaches. Many succesful cybersecurity attacks with severe impact resulted from this vulnerability. Adding a malicious dependency or to the new a library update or exploiting a flaw through remote code execution may be enough for the hackers to take full control over your app and steal your data.

Think about the Equifax data breach caused by the vulnerability in Apache Struts, an open-source web application framework. Its exploitation led he exposure of Social Security numbers, birth dates, addresses, and other sensitive information. 147.9 million Americans, 15.2 million British and about 19,000 Canadian citizens were affected in this massive breach. As a result of the settlement with FTC, Equifax was obliged to pay $300 million to a fund for victim compensation, $175 million to the states and territories in the agreement, and $100 million to the CFPB in fines.

That said, building everything in-house is out of question for the majority of companies. In such scenario, costs skyrocket, delays become unevitable, code loses quality, many innovations suddenly are out of your reach. So, what can you do to benefit open-source and stay safe at the same time? These good security practices will keep you safe.

1. Conduct regular dependency audits

Use tools like OWASP Dependency-Check, Snyk, or GitHub Dependabot to identify vulnerabilities in third-party libraries.

2. Choose well-maintained libraries

Prioritize libraries with a strong track record, active maintenance, and frequent updates. Review community activity, issues, and update history before adoption.

3. Lock and monitor dependency versions

Use version-locking tools (e.g., package-lock.json in npm, or requirements files in Python) to avoid unintentional updates. Regularly review updates and selectively apply only security patches.

4. Review library permissions and capabilities

Limit permissions for libraries, ensuring they only access necessary resources. Avoid libraries requiring broad permissions that may introduce security risks.

5. Scan for known vulnerabilities before deployment

Integrate vulnerability scanning into the CI/CD pipeline to detect and address library vulnerabilities before the code goes live.

Application security testing

Even the best security measures lose effectiveness when they aren’t backed by continuous testing. Cybercriminal strategies are constantly evolving, different types of security threats adapt, and your security methods should keep pace.

From time to time, it’s essential — even necessary — to say, “Let’s check” and verify how your application would respond to an attack at any given moment. Test how far attackers could get and which data might be within their reach. How to do it? The best approach is to combine several strategies.

Penetration testing

  • Purpose: To identify and exploit vulnerabilities from an attacker’s perspective, simulating real-world attacks.
  • When to conduct: Before major releases, after significant updates, and periodically to assess overall security posture.
  • Frequency: Every 6-12 months or after critical changes to the system.
  • Who conducts it: External security specialists or an internal dedicated security team

Static application security testing (SAST)

  • Purpose: To detect vulnerabilities in the source code by analyzing it for known patterns of insecure coding practices.
  • When to conduct: During the development phase, ideally at each code commit and build cycle.
  • Frequency: Continuously as part of the CI/CD pipeline for every code push or at least weekly scans.
  • Who conducts it: Integrated automatically via CI/CD, typically managed by DevSecOps or development teams

Dynamic application security testing (DAST)

  • Purpose: To find vulnerabilities in a running application by simulating attacks in a real-time environment.
  • When to conduct: After the application is deployed in a test environment, pre-production.
  • Frequency: Monthly or on-demand before each release to ensure runtime security.
  • Who conducts it: Security analysts or DevSecOps teams

Fuzz testing

  • Purpose: To discover unknown vulnerabilities by inputting unexpected, random, or invalid data to see how the application responds.
  • When to conduct: During later development stages, especially before production release.
  • Frequency: Quarterly or during major updates with complex input handling.
  • Who conducts it: Security engineers or automated by the testing team.

Compliance and regulatory requirements

Cyberattack protection is one thing, but as an application provider, you must also account for local and global data security requirements. It’s worth viewing these not as obstacles, but as guidelines and safeguards for your company. By adhering to these requirements, you protect both your clients and yourself—not only from reputational loss but also from hefty fines.

GDPR (General Data Protection Regulation)

  • Who does it apply to?: All organizations processing personal data of individuals residing in the European Union, regardless of where the organization is based.
  • What does it cover?: The regulation and protection of personal data, including privacy rights, data security, and obligations for data storage and processing.
  • Where does it apply?: Within the European Union, but it also applies to companies outside the EU that process EU citizens’ data.
  • What are the penalties for non-compliance?: Fines up to 20 million euros or 4% of the company’s global annual revenue (whichever is higher), potential data processing bans, and reputational damage.

HIPAA (Health Insurance Portability and Accountability Act)

  • Who does it apply to?: Healthcare organizations, medical service providers, health plans, business associates, and any organization processing health data in the United States.
  • What does it cover?: Protection of patient health data, including privacy, data security, and access control in the healthcare sector.
  • Where does it apply?: In the United States.
  • What are the penalties for non-compliance?: Financial penalties ranging from hundreds to several million dollars, potential criminal penalties, and the risk of accreditation and reputational loss.

ISO 27001 (Information Security Management System)

  • Who does it apply to?: Any organization seeking to build a robust information security management system and ensure data security, especially those subject to security audits.
  • What does it cover?: Requirements and guidelines for managing information security, including the protection of data confidentiality, integrity, and availability.
  • Where does it apply?: Globally – it is an internationally recognized standard accepted worldwide.
  • What are the penalties for non-compliance?: Risk of losing ISO 27001 certification, increased vulnerability to cyberattacks, loss of customer trust, and potential financial penalties due to non-compliance with other regulations.

SOC 2 (Service Organization Control 2)

  • Who does it apply to?: Organizations that provide data processing services to other companies, especially SaaS and cloud providers.
  • What does it cover?: Setting and following standards for data privacy, integrity, security, availability, and confidentiality of client data.
  • Where does it apply?: Primarily in the United States, international companies also adhere to SOC 2 when serving US clients.
  • What are the penalties for non-compliance?: Loss of customer trust, inability to partner with larger firms (especially in finance), potential contract cancellations, and reputational and financial losses.

NIS 2 (Network and Information Security Directive 2)

  • Who does it apply to?: Organizations in critical sectors such as energy, transport, banking, digital infrastructure, and digital service providers operating within the EU.
  • What does it cover?: Requirements for cybersecurity management and incident response, focusing on protecting critical digital infrastructure from cyber threats.
  • Where does it apply?: Within the European Union.
  • What are the penalties for non-compliance?: High financial fines, audits, increased regulatory oversight, potential operational restrictions, and reputational risk.

Securing Generative AI applications

If you’re considering developing a generative AI application but need guidance on security best practices, head to our AI Waves webinar. This session offers essential insights into securely building and deploying AI solutions. Join us to explore the latest trends in generative AI, learn from real-world examples, and understand how to safeguard your application from the start.

The most effective security practices are those which you implement right into the first development cycle and continue cultivating throughout the whole lifecycle of your software, including app maintenance and support. Extensive security testing and secure coding practices are essential from scratch. With the support of an experienced partner, keeping these principles will be much easier. Contact us if you are looking for a web and mobile development company with a verified security approach.

Top AI innovations delivered monthly!

The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest. You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more
Click me
Written by:

Radosław Holewa

Chief Technology Officer Radosław is the Chief Technology Officer at Miquido, leading the company's technological vision and strategy. With his extensive experience and innovative mindset, he ensures that Miquido stays at the forefront of tech advancements. Radosław is dedicated to fostering a culture of excellence and driving the development of cutting-edge solutions for our clients.

Dominika Słomka

Content Marketing Specialist As a specialist in strategy, inbound, and product marketing at Miquido, I create engaging content across blogs, social media, and video platforms. I leverage HubSpot to automate, analyze, and test marketing efforts, ensuring maximum effectiveness. My work is all about driving impactful marketing strategies that resonate with our clients.
Click me

The administrator of your personal data is Miquido sp. z o.o. sp.k.,... with its registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest. You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more