What security standards should your development platform meet

Choosing a development platform feels like a product decision. Pick the framework, choose the cloud provider, settle on a database, and build. But every one of those choices carries a security consequence that arrives later, often at the worst possible moment. We have seen this play out across enough projects to know that the platforms and patterns you select at the start determine what you can and cannot protect once real users arrive.

The platform choices you make early determine what you can and cannot protect once users arrive.

The security concerns that surface post-launch rarely come from exotic attacks. They come from gaps that were present from day one: a database with rules that were never tightened, an authentication flow that assumed users would behave, a payment integration that did not account for financial regulation, a set of third-party libraries that nobody updated. These are structural decisions, and they become harder to reverse as a product matures.

This article works through the security standards a development platform should meet before you commit to it, drawing on what we have encountered building products across messaging, payments, real-time data, and anonymous user interactions. Some of the decisions we got right from the start. Some we had to retrofit. Both are worth understanding.

Why your platform choice is a security decision

Developers tend to evaluate platforms on speed of build, ecosystem maturity, and cost. Security is often treated as a layer added afterwards, a set of checks applied once the product exists. The problem is that most platforms constrain what security is even possible once you have committed to them. Your database technology determines how granular your access rules can be. Your hosting model determines whether you have environment isolation. Your authentication provider determines whether user credentials stay internal or flow to third parties.

On the performance coaching survey app we built, the decision to skip a traditional API layer for the MVP had direct security consequences. Without an API acting as a controlled intermediary between the client and the database, we had to scrutinise every Firebase security rule with unusual care. There was no server-side layer to catch a malformed request before it reached the data. That is a workable position, but only if you go in knowing it and designing around it. We did, but it required considerably more attention to the database rule configuration than a conventional API-backed build would have needed.

Platform choices also interact with compliance requirements in ways that are not always obvious at evaluation stage. A platform that handles well in development can create legal exposure at scale. Knowing what security a platform can support is a prerequisite, not an afterthought.

Authentication standards and identity management

Authentication is the entry point to everything else in a product. Get it wrong and the rest of the security architecture is protecting a building with an unlocked front door. The standard debate is between social login, traditional email-and-password, and newer passive mechanisms. Each carries different security implications.

Social login is convenient but transfers user data to third-party platforms as part of the authentication flow. Traditional email-and-password creates a credential that can be intercepted, forgotten, or reused across services. We advise clients to consider a more passive approach: the user enters a phone number or email address and receives a one-time code that becomes their login. This removes password reset flows entirely, eliminates the risk of credential reuse, and keeps authentication internal rather than routing user data through external platforms. The simplicity is comparable to social login, but the data stays in the product.

Context matters here, though. On an anonymous messaging app we worked on, we had to put authentication right at the front of the flow, before users could do anything, because the product legally required us to tie messages back to specific users on the back end, even though the messaging appeared anonymous within the product itself. That was a legal requirement to handle potential abuse or harassment, and it overrode our usual preference for deferring login. The platform and the product's legal context together determined what authentication had to look like.

Database security and access control rules

Database security is where the gap between "it works" and "it is secure" most often lives. A database that returns the right data to the right user in testing can expose the wrong data to the wrong user in production if the access rules are not written carefully and tested against adversarial inputs, not just cooperative ones.

On the real-time messaging product we worked on, we used Firebase Firestore to store conversations and messages. The anonymous messaging feature required security rules that let users read messages without identifying the sender, which created a specific permission structure. We experienced performance slowdowns and initially assumed the cause was in the application code. After investigation, we found the issue was in the database layer itself. Adding extra indexes and reworking how messages were stored allowed the security permission checks to run far more efficiently, resolving the problem. The security rules were correct, but the data structure was forcing them to work harder than necessary.

A database that works in testing can expose the wrong data to the wrong user if access rules are not adversarially tested.

Access control needs to be role-based and granular. Each user should be able to read and write only the records they own. On the performance coaching survey app, audience members accessed their own unique response record via keys embedded in the QR code URL, with Firebase rules restricting each user to only their own record. That is the principle: the minimum access needed to complete the task, no more. According to Tech Prescient, organisations using automated policy enforcement and risk scoring often see a 70% reduction in over-privileged accounts in the first quarter of implementation.

When writing database security rules, test them explicitly against requests that should fail, not just ones that should succeed. A rule that blocks unauthorised reads in normal use can still pass a malformed request you did not anticipate.

Regulatory and legal compliance requirements

Regulation is not separate from security. It defines a floor beneath which your security posture cannot legally sit, and in some cases it dictates specific technical requirements that your platform must be capable of supporting. GDPR in the UK and EU determines how personal data is stored, accessed, and deleted. App store policies from Apple and Google add a further layer that can block distribution outright if your product fails their review criteria.

On the peer-to-peer currency exchange product we built, where users could exchange leftover foreign currency with other travellers at interbank rates, we built the core transfer mechanism well but did not factor in anti-money laundering requirements early enough. Apple flagged the product as a potential vehicle for money laundering because of its unlimited transfer capability. We had to go back and retrofit multiple compliance layers: more stringent Know Your Customer checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties.

That retrofit took time and delayed the product. Had AML requirements been part of the platform evaluation from the start, the architecture would have been built around them rather than adjusted to accommodate them.

Compliance requirements also shape what data you can collect, how long you can hold it, and what you must be able to prove about how it was used. Your platform needs to support audit trails, data deletion requests, and consent management before you need them, not after a regulatory question arrives.

Map the regulatory landscape for your product category before you write a line of code. AML, GDPR, and app store policy review criteria all have specific technical implications. Discovering them during build is expensive. Discovering them post-launch is worse.

Payment infrastructure and financial regulation

Payment handling sits at the intersection of user trust and legal obligation. The technical risks are real, but the regulatory exposure is often what determines whether a product can operate at all. Any platform that touches money needs to be clear about which financial regulations apply and how the payment infrastructure handles them.

On a property maintenance platform we worked on, the product connected landlords, tenants, and tradespeople, allowing job specifications to be uploaded, progress to be geotagged, and payments to be released on completion. The client needed something functionally similar to escrow: funds held until work was verified and signed off. Third-party escrow services were investigated but created legal complications. We chose Stripe Connect with delayed payouts instead, treating the product as a marketplace app. This gave us the escrow-like outcome while keeping the platform fully compliant, with Stripe handling the legal and financial regulation requirements. The key decision was staying within Stripe's existing regulatory framework rather than building something adjacent to it that would require separate financial authorisation.

Payment Card Industry Data Security Standard compliance is non-negotiable for any product handling card data. Using an established payment processor that holds PCI DSS certification transfers much of that obligation, but your platform still needs to handle tokenised data correctly and avoid ever logging raw card information. The architecture around payment flows needs the same scrutiny as the payment processor itself.

API security and data-sharing boundaries

APIs are the connective tissue between your product and everything outside it, including other services, partner platforms, and third-party data providers. They are also where a significant share of security incidents originate. The risk is not only inbound attack: it is also what your own API exposes if it returns more data than it should, or accepts more input than it validates.

API design decisions also determine what data-sharing relationships are even possible. On a toll management project, we had to educate the client about how APIs work and what it would take to establish formal data-sharing relationships with established toll operators. We made the case that a new, unproven product would struggle to negotiate API access with incumbents, and that the smarter approach was to launch using a preloaded credit model and pursue API integrations later, once the platform had established credibility. The client accepted this staged approach. The security implication was that rushing into API relationships with third parties before those relationships were properly defined would have created data-sharing boundaries that were informal and therefore unenforceable.

API keys exposed in public repositories are a common and avoidable failure mode. According to Serverion, 61% of organisations have accidentally exposed secrets such as API keys in public repositories. Your platform should support secrets management that keeps keys out of the codebase entirely, using environment variables or a dedicated secrets manager rather than hardcoding credentials anywhere that version control can reach them.

• Validate all API inputs server-side, regardless of client-side validation already in place
• Return only the data the request actually needs, not the full record
• Rate-limit all endpoints to reduce the impact of credential stuffing and automated probing
• Use short-lived tokens rather than long-lived API keys wherever the integration allows
• Log API access in a way that makes anomalous patterns detectable without storing sensitive payload data

Handling anonymous or sensitive user data safely

Anonymous products are not low-risk products. The absence of visible identity creates a particular set of security and safety obligations, because the architecture has to maintain traceability on the back end even when the product surface presents none to the user. Getting this wrong creates both legal exposure and the conditions for serious user harm.

On the anonymous messaging app we worked on, authentication had to come first precisely because anonymity on the surface did not mean anonymity in the system. We needed the ability to tie messages back to specific users in the event of abuse or harassment, which meant every message had a traceable owner even though no other user could see that. We also added in-product reporting features so users could escalate concerns about inappropriate or bullying messages to the client's admin team. The product looked anonymous to users. Under the surface it was fully attributable, because the legal and safety requirements demanded it.

The tension in anonymous products is between the privacy promise users expect and the accountability infrastructure the product legally requires. Both need to be present. The platform architecture has to support storing identity in a way that is inaccessible to other users but accessible to administrators with appropriate authorisation, and that access itself needs to be logged.

If your product involves anonymous user interactions, document the back-end attribution model and the conditions under which identity can be surfaced before you build. This protects both users and the business if a legal question arises later.

Infrastructure as code and environment consistency

Security encompasses what the code does and the reliability and consistency of the environments that code runs in. A product that behaves correctly in a staging environment and differently in production has an environment problem, and environment problems create security gaps because they produce untested behaviour at the worst possible time.

Storing infrastructure as code in a version control repository changes this. The environment becomes reproducible from the codebase rather than from a set of manual steps that may or may not have been followed consistently. On the performance coaching survey app, being able to spin up clean environments quickly for testing meant that the configuration we tested was the configuration we shipped. There was no drift between what QA ran against and what went to users.

The practical benefit for security is that a new environment, whether for a penetration test, a QA cycle, or a user research session, is spun up from the same source of truth as production. Manual deployment processes introduce variation, and variation creates the conditions for misconfiguration. A server setting that was applied in production but forgotten in staging is a vulnerability that only appears when something goes wrong.

Technical debt as a security liability

Technical debt is usually framed as a development speed problem: the code gets harder to change, features take longer to build, and the codebase becomes brittle. That is true, but in products where security is central to the value proposition, technical debt is also a direct security risk. Fragility and trustworthiness cannot coexist.

On a communications product we worked on, the client repeatedly declined to allocate time to address accumulating technical debt. The reasoning was familiar: there was always a feature that felt more urgent. The debt was left unresolved until the product became fragile enough that its robustness was genuinely compromised. That was the point at which the client accepted that core mechanisms needed reworking. The cost was considerably higher than it would have been if the debt had been addressed progressively, and the timing was the worst possible: users had formed expectations about reliability, and the product was visibly failing to meet them.

The security dimension here is specific. A fragile product has unpredictable behaviour under unusual inputs. Unpredictable behaviour is what attackers look for. A security rule that works under normal load may not hold under a malformed request or an unexpected access pattern. Debt that degrades the structural integrity of a product also degrades its security posture, because the two are not separate things.

Only 52% of developer respondents said they always consider security when evaluating a new third-party library, according to Veracode research via Dark Reading, compared with 67% who prioritise functionality. Libraries that are never revisited accumulate known vulnerabilities, and the same Veracode research found that 69% of vulnerabilities in third-party libraries involve only a minor patch that would rarely cause breakage. Debt is not just structural: it is also the libraries sitting at a version from three years ago because nobody scheduled the update.

Conclusion

Security in digital products is a set of decisions made during the build, often before a single line of product code is written. The platform, the authentication model, the database structure, the payment infrastructure, and the deployment approach all carry security consequences that arrive later and are expensive to reverse.

What we have found across projects involving real-time messaging, anonymous user interactions, peer-to-peer payments, and performance data collection is that the security gaps that matter most are structural, not incidental. They come from decisions made without full awareness of their implications: choosing to skip an API layer without tightening the database rules to compensate, building a transfer mechanism without factoring in AML requirements, letting technical debt accumulate in a product whose core promise was trustworthiness.

The standards worth meeting are a set of questions worth asking at the point when the platform decision is still open: what can this platform protect, what does it leave exposed, and what happens when a legal or regulatory requirement arrives that the architecture was not built to handle?

If you are making platform decisions for a new product, or reconsidering the security posture of something already in market, we are glad to think through it with you. Start the conversation about your product's security architecture.

Frequently Asked Questions