Ensuring Security: A Guide for Web and Mobile Application Development

If you’re anything like us, cracking open a clean text editor to build a new application or service is an empowering experience (after all, the endless possibilities sit right at the intersection where our fingertips meet our imagination). Like many before us, we set out to build the core of our application ensuring we crush our user’s pain points!What we quickly learned, was more often than not, what we took for granted was the exhaustive degree of security elements required to meet production readiness for any public release. This was often considered later in the build cycle and resulted in unexpected complexity that consumed a massive amount of time and maintenance overhead. In some worst-case scenarios, it can be written-off as technical debt or downplayed because it is only a “first release” and “it’s in the roadmap”. Security frameworks, standards, concepts, and services can often be overlapping, complex, and increasingly difficult to implement correctly. Compounding the problem — right!?So here we have compiled a practical list that everyone should know when starting the development of their project.

If anything, this:

Don’t do it yourself: Chances are what you need already exists and building a custom implementation can leave you vulnerable. Modern applications/services have a high degree of interoperability with other applications which conform to industry standards for universal federation (the majority of authorizations are done on behalf of the user and not by the user).

Every use case is different: Use the appropriate standards that make sense for your requirements. Different use-cases require the implementation of varying depths of security factors. Note: There is an inverse relationship between usability and factors of AuthN/AuthZ.

Complexity is Compounding: Basic authentication is quite simple to implement (like accessing a single frontend resource). The introduction of custom flows and varying scopes will quickly become exponentially complex, difficult to manage and increase the cost of maintenance.

Less is More: The bigger the area of your app/services that are publicly accessible, the greater the risk! Make sure you keep all your services in your private network and only expose what is absolutely necessary. It’s always best to use your hosting provider's recommended configurations.

Plan A, B & C: No implementation is foolproof! Usually, malicious hackers have unscrupulous ways to authenticate themselves as legitimate users (for example: gaining physical access to a user’s valid credentials or keys.) Rather the objective is to mitigate risks until the probability of a breach is highly unlikely. So even though it will be unlikely - read a contingency plan. Ensure your tools allow you to:

• Identify the path of the breach,
• Understand the size and scope of the resources affected,
• Eliminate any further access to the affected resources (until a resolution has been shipped) without affecting uncompromised resources/users,
• Investigate and improve the measures in place to mitigate additional incidents.

Always be transparent with your users if they have been affected. Of course, they’ll most probably be pretty pissed 😠 but you could potentially help them avoid further harm with other services that could have been indirectly compromised.

More Practically;

Secure a SPA (Single Page Application): SPA’s have relatively low complexity when it comes to securing services. They are served by a single frontend service which will require authentication for your users. Basically requiring a secure user directory. The best approach would be to use an identity provider service/library (like , *, ). These services or libraries will provide you with all the functionality you need to manage users, allow for Single Sign-On, enable Two-factor authentication, custom branding, etc.

*Note: Okta has acquired Auth0. IMO Okta can be pretty 💰💰💰

Secure A Modern Web (or Mobile) Application: Most Modern Web/Mobile Applications have microservice architectures (generally our preference when developing) and can have a varying set of frontend and backend service permutations. In this case, you will not only need authentication validating that the user is who they say they are. You will also need to authorize requests to validate that they have been granted the required permissions to access the resource (Authorization).

The best approach to consider would be an implementation of OAuth2.0 & OIDC (which will be useful now or in the future 🔮 for allowing 3rd party application authorisations on behalf of your user). The following will become of great use to you with OAuth2.0:

• The application doesn’t need to store the user’s username and password.
• Tokens can have a restricted scope (i.e only grant read access to a resource)

Practically a good way to think about this under the definition of OAuth2 is that the endpoints of your application will become your protected resources and your client application the resource server. There are some good solutions out there to achieve this (, , , ). The best way for you to go can vary based on the specifics of your requirements but consider the following:

• Remember, Complexity is compounding. Assess the degree of complexity and effort required when needing customisations, particularly when it comes to the flows required and attaching your endpoints. Make sure more functionality does not equal exponentially more complexity.
• Ensure policies and permissions are simple to create and manage.
• The management of users and user groups settings should be possible to do independently or by independent groupings. Having the ability to set up hierarchical links (users, roles, permissions, primary accounts) is a must if they are required in your use case.
• Primary Accounts or Account spaces that can assign users and allow for subscribing to apps and services are a life-saver (A must for B2B apps).
• Use solutions that are as unobtrusive as possible to your core code.
• Having good responsive support backing will be important.

Secure a Server-side Service: A server-side service (API as a service type product) will not require its own client and serve users (usually other clients/machines) through automated responses to requests. Think most fintech* services.

Like above, OAuth2.0 is a great way to go. The main factor is that you will need to allow users to register their Client ID in return for a Client Secret, which in turn will be traded for an access token. This token will then be passed in the requests validating the granted permissions required to securely access your resources.

Alongside the considerations in securing a modern web app above. You should also think about the following:1. How easy is it for users to register their clients, obtain a secret to generate a token?2. Ensure access policies are easily manageable for your issued tokens:

• Token lifetime/expiration
• Token refresh management
• Request rate limits

3. Encryption: JWTs inherently contain data so using a good encryption algorithm is essential. This coupled with the Client Secret acting as a server-side verifier is what keeps things random, verified and safe!

Again there are some good solutions out there to achieve this (, , , ).

Note: For the specific use of fintech’s or financial services it’s important to ensure that your security meets the standard regulatory requirements (PSD2, SCA, etc…)

Some Fundamentals;

Frameworks: Consider  as a leading framework for modern applications that will best serve you in 99.9% of your use cases. It is relevant, practical, and effective in defining how to securely access and manage your resources. Although, it is just a framework, and the ‘how’ when it comes to actual protocol standards will still need to be catered for.

Protocols: Consider  as a protocol, it is built on top of the OAuth2.0 framework. It is a protocol defined by a standard set of claims to securely authenticate users. This will allow your app/service to seamlessly work with external identity services.

Tokens: are used by the OIDC. When using JWTs make sure that you eliminate common vulnerabilities when minting tokens by using services/libraries that use good encryption standards (HMAC + SHA256, RSASSA-PKCS1-v1_5 + SHA256, ECDSA + P-256 + SHA256).

Authorization Servers: You will need an authorization server running to validate and grant permissions to your resources. Your authorization server will issue tokens and do the necessary validations for permission granting as per your desired workflows. This can be tricky, consider using an existing service.

What’s that Buzz ⏰:

These are concepts that you will commonly encounter from a brief google search. You should familiarize yourself with a basic understanding of them (at minimum):

OAuth2.0: OAuth 2.0 () is the industry-standard framework for Authorization. This standard defines specific authorization flows to obtain limited access to an HTTP service.

OIDC:  is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It defines a standard set of claims to securely authenticate users.

SAML2: Security Assertion Markup Language 2.0 is an XML-based standard for exchanging authentication and authorization data between IdPs and service providers to verify the user’s identity and permissions, then grant or deny their access to services. It is extremely verbose and clunky. Good for corporate active directory type use cases.

OWASP:  is a nonprofit foundation that works to improve software security. OWASP Top 10 outlines the most critical security concerns for web application security.

WAF: A Web Application Firewall helps to protect your web applications or APIs against common web exploits and bots that may affect availability, compromise security, or consume excessive resources.

RBAC: Role-Based Access Control is the idea of assigning permissions based on their role within an organisation/ecosystem. Makes for easier access management and is less prone to error than assigning permissions to individual users.

AuthN: Authentication is the process of determining whether someone or something is, in fact, who or what it declares itself to be.

AuthZ: Authorization is the process of determining whether someone or something has, in fact, the necessary grants to access a specific resource or function.

JWT: JSON Web Token is an open, industry-standard () method for representing claims securely between two parties.

Zero Trust Security: A security-based concept which implies that every user is treated as untrusted by default whether in or outside the network. It requires every transaction to be authenticated, authorized, and continuously validated before being granted access.

Access Token: Access tokens are credentials used to access protected resources. They are used as bearer tokens. A bearer token means that the bearer (who holds the access token) can access authorized resources without further identification. These tokens usually have a short lifespan for security purposes. When it expires, the user must authenticate again to get a new access token limiting the exposure of the fact that it is a bearer token.

Refresh Token: A Refresh token is a long-lived token compared to the access token and is used to request a new access token in cases where it is expired. It can be considered as credentials used to obtain access tokens. It’s allowed for long-lived access and is highly confidential.

🤖 LeZa is a security as a service built by our devs with love for other devs. We have no other affiliation, interest, or connection with any other tool, library, framework, protocol or company mentioned - they copped a mention based on our experiences.

This article was first published .