# Hyperscale Consulting > Hyperscale Consulting is a cloud security consultancy specialising in AWS security assessments, application security, cloud governance, infrastructure hardening, data protection, and rapid incident response. We help businesses build secure, compliant cloud environments. ## Services - [AWS Cloud Security Assessment](https://hyperscale.consulting/security-assessment): Get a comprehensive assessment of your AWS cloud security posture with actionable, prioritized findings. Fixed-price (£2,500) comprehensive AWS security assessment covering IAM, networking, encryption, logging, and workload security. Includes a prioritised findings report and remediation roadmap. What we assess: IAM policies and privilege sprawl, S3 bucket permissions, VPC and network configuration, CloudTrail and GuardDuty settings, workload and container security. Process: Discovery call to read-only access setup to in-depth assessment to detailed report walkthrough. Deliverables: Executive summary, severity-rated findings with remediation steps, prioritised roadmap, findings walkthrough call. Compliance mapping: CIS AWS Foundations Benchmark, NIST CSF, ISO 27001, SOC 2, AWS Well-Architected Security Pillar. - [Application Security Testing](https://hyperscale.consulting/application-security): Application security testing and secure code review for UK SaaS teams. We find the vulnerabilities automated scanners miss. Free initial source code scan. We help teams design, develop, and deliver secure applications from the start by embedding security into the software development lifecycle. Offerings: Secure architecture review and threat modelling, secure SDLC enablement, CI/CD hardening and automated security testing, security champions programmes. What we cover: Architecture review, threat model analysis, code design and security vulnerabilities, API and integration security, infrastructure and configuration, access control and authorisation, data controls, dependency and supply chain security. Approach: SAST and DAST integration, secure coding training, developer-focused code reviews, automated pipeline security gates. - [Cloud Governance](https://hyperscale.consulting/cloud-governance): Strong AWS governance, identity, and compliance controls that scale with your business. Design and implement a secure multi-account AWS strategy using AWS Organizations, Control Tower, and Service Control Policies. Align governance with ISO 27001, NIST CSF, and SOC 2. Offerings: Multi-account landing zones and account separation, centralised IAM and identity federation, automated policy enforcement via AWS Config and SCPs, guardrails for safe self-service at scale. Benefits: Contain incidents within defined boundaries, demonstrate compliance to auditors, enable teams to self-serve safely, reduce overhead through standardised patterns and automation. - [Data Protection](https://hyperscale.consulting/data-protection): Protect sensitive data with best-practice encryption, key management and access controls. Protect data throughout its lifecycle by applying best practices in classification, access control, and encryption across AWS. Offerings: Automated data discovery and classification (AWS Macie), role- and attribute-based access control, encryption at rest and in transit with centralised KMS key management, data lifecycle and retention policies. Compliance: Supports GDPR, ISO 27001, and SOC 2 data protection requirements. Benefits: Reduced breach risk, improved compliance alignment, optimised storage costs, visibility of where sensitive data resides and who can access it. - [Infrastructure Security](https://hyperscale.consulting/infrastructure-security): Harden cloud infrastructure, networks, and workloads against modern threats. Implement AWS best practices for network segmentation, traffic control, and compute protection tailored to your workloads. Offerings: Network zoning, inspection, and segmentation; zero trust architecture patterns; EC2 and container hardening; vulnerability management and automated patching via AWS Systems Manager. What we harden: VPC design and subnet segmentation, security groups and network ACLs, EC2 instance configuration, container and Kubernetes security (EKS pod security standards), secrets management, managed service configuration (RDS, EKS, Lambda). Benefits: Defence-in-depth against lateral movement, layered protections, automated updates and secure defaults. - [Rapid Incident Response](https://hyperscale.consulting/rapid-incident-response): High-impact incident response to contain, eradicate and recover quickly from security incidents. Build the capability to detect, investigate, and recover from security incidents with clear playbooks and measurable objectives. Offerings: Centralised logging and monitoring strategy, incident response playbooks and runbooks, business continuity and disaster recovery planning and testing, RPO/RTO definition and testing. Incident process: Triage to containment to evidence preservation to eradication to recovery to post-incident review. Evidence to preserve: CloudTrail logs, VPC Flow Logs, CloudWatch Logs, S3 access logs, EBS snapshots of compromised instances, IAM credential reports. Benefits: Minimise downtime and data loss, clear playbooks for who does what during incidents, faster recovery lowers business and reputational costs. - [Security Coaching & Accelerators](https://hyperscale.consulting/coaching-and-accelerators): Upskill your teams with expert coaching, playbooks and accelerators for secure-by-design. Transform team security capabilities through expert coaching and proven accelerators. Coaching services: Team and engineering manager mentoring on secure coding, threat modelling, reliability, chaos testing, and incident response. Custom workshops and training. Shift-left security via pair programming. C-level security training covering risk management, incident response, and compliance. Accelerators: Packaged security products that remove implementation friction, reusable security and cloud workload patterns, secure IaC patterns and migrations. Benefits: Practical hands-on guidance, accelerated capability building, reusable patterns, embedded knowledge that persists beyond the engagement. - [Web App Pen Testing](https://hyperscale.consulting/web-app-pen-testing): Professional web application pen testing that finds what scanners miss — business logic flaws, access control gaps, and API vulnerabilities. OWASP-aligned, free retest included, letter of attestation on completion. Professional web application penetration testing covering OWASP Top 10 and beyond. Starts with a free 30-minute scoping assessment. Testing coverage: Injection vulnerabilities (SQLi, NoSQL, command injection), authentication and session management, XSS and CSRF, access control (IDOR, privilege escalation), data protection weaknesses, API security (REST, GraphQL), business logic flaws, server-side vulnerabilities (SSRF, XXE). Methodology: 6-step CREST-aligned process: scoping, intelligence gathering, vulnerability analysis, exploitation and validation, reporting, re-testing. Approaches: Black box (external attacker), grey box (authenticated user), white box (full source code access). Deliverables: Executive summary, detailed technical report with evidence, prioritised remediation guidance with code examples, free re-testing within 30 days, letter of attestation, debrief session. Pricing: Simple apps £2,500-£5,000; standard apps £5,000-£12,000; complex apps £12,000-£25,000+. Compliance: Supports PCI DSS, ISO 27001, SOC 2, Cyber Essentials. - [MSP Security Governance](https://hyperscale.consulting/msp-security-governance): Security governance frameworks and controls for managed service providers operating in cloud environments. Continuous technical oversight and validation of your MSP security posture, acting as your internal control function without building an entire governance team. The problem: Your security posture is only as strong as your MSP. Point-in-time certifications do not reflect today's risk. Shared responsibility boundaries are often ambiguous. How it works: Read-only access to your cloud environments for independent verification, automated continuous scanning of configurations and access patterns, standards-based assessment against NCSC 14 Cloud Security Principles and AWS Well-Architected Framework, centralised evidence platform with real-time dashboards, clear shared responsibility documentation. Benefits: Confidence in your MSP relationship, reduced financial and reputational risk, clear accountability, 80%+ reduction in manual evidence collection effort, strategic intelligence for MSP renewal and renegotiation decisions. - [Cloud Migration Services](https://hyperscale.consulting/cloud-migration): AWS cloud migration services for UK businesses. Legacy and modern application migration with security built in from day one. Free 30-minute consultation. A UK cloud migration company providing full-stack application hosting, migration, scaling, and security hardening with flexible fractional support. Free 30-minute consultation with custom quote. What we deliver: Legacy application migration planning and execution, cloud-native architecture design, Infrastructure as Code implementation, CI/CD pipeline setup, security and compliance integration, multi-account governance structure, cost optimisation. Typical project sizes: Small apps £5k-£15k (2-4 weeks); medium apps £15k-£40k (4-8 weeks); complex/enterprise apps £40k-£100k+ (8-16 weeks); governance-only £8k-£25k (3-6 weeks). Ongoing support: Ad-hoc sessions at £50/30 min, or monthly retainers from £400/month (10 hours) to £1,200/month (40 hours). Compliance: SOC 2, ISO 27001 technical controls implementation. - [Expert Sessions](https://hyperscale.consulting/expert-sessions): Focused expert sessions to upskill your team on specific cloud security topics and challenges. Pay-as-you-go expert security, development, and cloud support. First 30-minute session free, then £50 per session. No contracts or commitments. Perfect for: AI-assisted development support (Lovable, Bolt.dev, v0.app, Base44, Builder.io), automated testing strategy, security advice and incident triage, operational troubleshooting, migration planning, scaling strategy, AWS debugging. How it works: First session free (security assessment, NDA signing, problem discovery) then subsequent sessions £50/30 min, book on demand. Credentials: AWS Certified Security Specialty, Solutions Architect Professional, DevOps Engineer Professional. Over 20 years combined experience. - [AWS Security Accelerator](https://hyperscale.consulting/aws-accelerator): Limited to 20 companies. Get a noise-free AWS security roadmap tailored to your stage, pick one security priority, and bake in security practices without slowing down. Limited early adopter programme for 20 companies (10 startups, 10 scaleups). Comprehensive AWS security assessment plus co-created security accelerators at a discounted pilot rate. For startups: Establish security foundations before scaling. Identify gaps, get a prioritised roadmap, implement one high-impact security improvement without halting feature delivery. For scaleups and SME: Optimise and mature security at scale. Address security technical debt, improve compliance posture, mature practices across teams without disrupting shipping velocity. Process: Comprehensive root-cause assessment and architecture review to business-context roadmap to select one high-impact focus to co-create and implement the missing capability to sustainable velocity. The exchange: Discounted pilot rate in return for feedback on accelerators and a private case study upon success. - [Content Security Policy Review](https://hyperscale.consulting/csp-review): Free security headers check for UK SaaS teams, then CSP implementation that blocks injected scripts without breaking your app. Report-only rollout, then enforce. Security headers check: we scan your live site free of charge and report on Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy and Permissions-Policy, explaining what passes and what fails. A Content Security Policy tells the browser which sources it may load scripts, styles, fonts and images from, so an injected script simply does not execute. What we do: audit the security response headers on your live site (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy); inventory every legitimate script, style, font and third-party service such as payments, booking widgets, live chat and analytics; build a policy around exactly those sources; deploy in report-only mode and monitor violations against real traffic; then enforce and retest. Approach to inline scripts: nonce or hash based, rather than unsafe-inline. Deliverables: header audit report, ready-to-deploy policy for your stack, violation monitoring, supporting headers configured, retest after enforcement, written handover for your team. Entry point: free scan of your live security headers, no commitment. Full pricing quoted after a short scoping call. Compliance: supports Cyber Essentials, ISO 27001, SOC 2 and enterprise customer security questionnaires. - [Automated Security Remediation](https://hyperscale.consulting/automated-security-remediation): Vulnerability remediation and patch management automated for UK teams. We review your environment, then build a safe automated process that fixes findings fast. Vulnerability remediation is the work of fixing a security weakness so it no longer exists. Remediation removes the weakness, mitigation only makes it harder to exploit, and acceptance is a recorded decision to live with it. Patch management is automated first: dependency updates, operating system and container base image patching, staged rollout with health checks, tested rollback, and an audit record for Cyber Essentials or ISO 27001. Bespoke automated security remediation: we review your environment and existing processes, then build an automated process that remediates vulnerabilities safely in your stack. Four stages: review of environment, scanners and current remediation workflow; design of the safe remediation path including guardrails, staged rollout, health checks, approval gates and tested rollback; build into your CI/CD and infrastructure as code so every fix is a reviewable change with an audit trail; handover with runbooks, monitoring and a team walkthrough. What gets automated: dependency and operating system patching, misconfiguration drift correction, secret rotation, IAM permission tightening, TLS and security header baselines, scanner finding triage and deduplication. What stays manual: business logic flaws and architectural weaknesses, plus anything the client designates as approval-only. Benefits: time from finding to fix drops from weeks to hours, repeat findings stop recurring, compliance evidence is produced automatically, and the automation is owned by the client with no lock-in. Entry point: free scoping call and review of your current remediation process. Pricing quoted after scoping. - [Cloud Cyber Essentials](https://hyperscale.consulting/cloud-cyber-essentials): Fix your cloud security gaps and build the team practices to keep them closed. Cloud governance, infrastructure hardening, data protection, incident response, and MSP security governance all under one roof. A bundled cloud security service covering the five essential disciplines organisations need to close security gaps and keep them closed. Services included: Cloud Governance (multi-account landing zones, centralised IAM, automated policy enforcement), Infrastructure Security (network segmentation, zero trust architecture, workload hardening, patch automation), Data Protection (automated data discovery and classification, role-based access control, encryption at rest and in transit, lifecycle policies), Rapid Incident Response (24/7 threat detection, incident triage and containment playbooks, forensic investigation, post-incident remediation), MSP Security Governance (standardised controls across client environments, automated compliance reporting, scalable governance frameworks). Approach: We fix your security gaps then help your team adopt the practices to stop them coming back. Free consultation, no commitment required. - [App Studio](https://hyperscale.consulting/app-studio): Build your SaaS with AI and know it's secure before it goes live. App Studio catches vibe coding security vulnerabilities, enforces GDPR-ready access control, and guides non-technical founders from idea to production-ready software — free to start. Build your SaaS with AI and know it's secure before it goes live. App Studio catches vibe coding security vulnerabilities, enforces GDPR-ready access control, and guides non-technical founders from idea to production-ready software — free to start. ## Content - [Blog](https://hyperscale.consulting/blog): Expert insights on AWS security, cloud security assessments, DevSecOps, and secure by design best practices. - [Case Studies](https://hyperscale.consulting/case-studies): Real-world cloud security transformation stories. - [Events](https://hyperscale.consulting/events): Cloud security webinars, workshops, and events. - [Puffin Cottage Holidays](https://hyperscale.consulting/case-studies/puffin-cottage-holidays): Learn how Hyperscale Consulting helped Puffin Cottage Holidays build cyber resilience in AWS. Puffin Cottage Holidays is a UK-based holiday cottage rental business managing bookings and customer data through cloud-hosted systems. The company needed to strengthen its AWS security posture and build resilience against ransomware and other cyber threats. Challenge: The business lacked visibility into its AWS security posture, had no formal incident response plan, and was concerned about the growing threat of ransomware targeting small hospitality businesses. Customer payment and personal data required stronger protection. Approach: Hyperscale Consulting conducted a comprehensive AWS security assessment covering IAM, networking, data protection, and logging. Findings were prioritised by risk and mapped to a remediation roadmap. Phase 1 - Foundations: Remediated critical IAM findings including overly permissive policies and unused access keys. Enabled CloudTrail, GuardDuty, and Security Hub across all regions. Implemented S3 Block Public Access and bucket versioning for data recovery. Phase 2 - Resilience: Designed and implemented a backup and recovery strategy with tested RTO and RPO targets. Created incident response playbooks covering ransomware scenarios. Configured automated alerting for suspicious activity patterns. Phase 3 - Ongoing governance: Established a lightweight governance process for reviewing security findings monthly. Implemented AWS Config rules to detect configuration drift. Provided security awareness guidance for the engineering team. Outcomes: Achieved a 70% reduction in high and critical security findings within 60 days. Established tested recovery capability with a 4-hour RTO for core booking systems. The team now has clear ownership of security responsibilities and a roadmap for continued improvement. Testimonial: Hyperscale gave us clarity we did not have before. We knew security was important but did not know where to start. The assessment and roadmap made it straightforward to prioritise and act. - [4eyez](https://hyperscale.consulting/case-studies/4eyez): How Hyperscale Consulting helped 4eyez transform a vibe-coded prototype into a secure, GDPR-compliant, production-ready fleet CCTV management platform in just 4 weeks. 4eyez provides CCTV solutions for taxis and private hire vehicles. Founder Craig had a working prototype built using AI-assisted development that demonstrated the concept but was not safe to put in front of real customers handling real data. Problems identified: Unauthorised data access flaw allowing users to view or alter records belonging to other customers. Business logic vulnerabilities allowing booking and certification steps to be skipped or manipulated. Data residency requirements not met, creating legal exposure. No analytics or data control capability for growth. Solution: Hyperscale Consulting rebuilt the platform from the ground up in 4 weeks with proper multi-tenant access control, GDPR-compliant UK data residency, and a full feature set including customer portal, installation booking, certificate management, fleet management, warranty tracking, support ticketing, council contacts, and email notifications. Delivery timeline: Week 1 - security review, threat modelling, and architecture design. Week 2 - access control, tenant isolation, customer portal, and fleet management. Week 3 - booking system, certificate management, warranty tracking, ticketing, GDPR compliance, and email notifications. Week 4 - security hardening, testing, CI/CD setup, documentation, and handover. Outcomes: Platform passed security review and is ready for real customers. Every user role enforces strict data access boundaries automatically. All data stored in the UK, encrypted, and GDPR-compliant. Infrastructure fully owned and controlled by 4eyez. Delivered in 4 weeks on budget. Testimonial: I found Henry and Andy very approachable, understanding immediately what was required for taking my vibed app into the real world. I was very impressed with their understanding of what was required and delivered in time and on budget. - Craig, Founder, 4eyez - [Engineering for Resilience: Defeating Ransomware](https://hyperscale.consulting/events/engineering-for-resilience-defeating-ransomware): Free webinar: learn how to engineer cloud systems that can recover at speed from encryption-based ransomware attacks. Free online webinar on December 16, 2025 at 11:00 AM GMT (1 hour). Learn how to engineer cloud systems that can recover at speed from encryption-based ransomware attacks. Includes live demonstration of attack and recovery workflow. The challenge: Ransomware has evolved into one of the most reliably successful business models in cybercrime. Recent government figures show ransomware attacks have doubled year on year. 81% of all UK businesses that suffer a cyber attack are small and medium-sized businesses. In 2024, nearly 200 million pounds was paid out in cyber insurance payments, an increase of over 230% from the previous year. Prevention and detection are no longer enough. What you will learn: Core resilience principles for rapid recovery from ransomware attacks. Strategic roadmap for improving organisational cyber resilience. Live attack demo showing a real encryption-based ransomware attack and corresponding recovery workflow. Practical implementation steps to limit damage and shorten downtime. Key takeaways: Why prevention and detection alone are no longer sufficient. The core principles of engineering for cyber resilience in cloud environments. How to design systems that can recover at speed following a disruptive cyber intrusion. Practical cloud security practices that give your organisation a decisive advantage. Actionable steps to begin improving your resilience posture. Who should attend: CTOs, CISOs, and IT Directors responsible for organisational resilience. Cloud architects and engineers designing critical systems. Security professionals looking to enhance recovery capabilities. Founders and business leaders concerned about ransomware risk and business continuity. Anyone responsible for incident response planning. Registration: Free via Eventbrite. Limited spaces available. ## Blog Posts - [Build your demo and sell, sell, sell](https://hyperscale.consulting/blog/2026-build-your-demo-and-sell): How we used demo, sell, build to validate our second product — starting with a real problem, a real customer, and a room full of founders willing to tell us what was wrong. Andy sat in a room full of founders at Cooper Lounge Chat, a step up from pitching the idea at Start Social the week before. He had minutes to show them what we had built and explain why it mattered. We had been working on the product for three weeks. It was not finished. That was the point. This was our second attempt at building a product as a business. The first had taught us what happens when you build for yourself — you end up with something sharp and well-engineered that nobody else is asking for. This time we did it differently. We started with a problem we had already been paid to solve, for a customer we had already helped, inside an ecosystem that would tell us honestly whether we were on the right track. ## Starting with the problem, not the product [Ash Maurya](https://ashmaurya.com/) has a framework he calls demo, sell, build. The order matters. You do not build the product, then demo it, then try to sell it. You demo first, sell second, build last. The logic is simple: if nobody will commit after seeing the demo, the product is not worth building yet. We came at this from a slightly different angle. We had already done client work — rebuilding Craig's fleet CCTV platform at 4eyez, replacing spreadsheets and scattered data with a single secure application. That engagement showed us the pattern. Founders and SME owners were building with AI tools, hitting walls around security and scalability, and needing someone to make the thing fit for production. The problem was clear. The question was whether we could turn a repeatable service into a product that did the same job faster. ## The Lean Canvas as a forcing function We filled in the Lean Canvas before writing a line of code. Not because it is a perfect tool — it is a snapshot on one page and reality is messier — but because it forces you to name the things you are assuming rather than the things you know. Who has this problem? How badly? What are they doing today instead? What would make them switch? The canvas made us commit to answers we could test. Our customer segments in the early stages. The channels we thought would reach them. The unfair advantage we thought we had (a decade of production engineering and a genuine security background, not a thin wrapper around an AI). And the revenue model — would founders pay for a tool, a service, or something in between? We were part of the Cooper Project at Sheffield Technology Parks, which gave us something most founders in the early stages do not have: a room full of people building businesses who would look at our canvas and tell us where it was weak. That proximity mattered more than any framework. If you want a clear walkthrough of how to use the Lean Canvas to clarify a business idea, [Hadiza Sa-Aadu's talk on The Kansas City Public Library channel](https://www.youtube.com/watch?v=jyh4p0yUzis&t=83s) covers the methodology well. ## Building the demo We built a working demo in three weeks. Not the full product. Not the infrastructure. A version that showed the core thing clearly enough that a founder watching it could say either "I would use that" or "that is not for me." The demo covered the path from problem to outcome: a founder describes their idea, the system turns it into structured requirements, validates the logic, flags the security gaps, and shows what ready for production looks like. It was real enough to be credible and incomplete enough to be honest about where it was going. ## Selling it in a room Andy pitched at Startup Social. Twelve minutes. A room of founders, operators, and builders in the early stages of their own things. Afterwards, he posted about it on LinkedIn and then gave a demo in front of founders on the Cooper Project. The responses were direct — people told us what they liked, what confused them, what they would pay for and what they would not. Every piece of that feedback was more useful than a month of building in isolation. The sequence matters because it aligns risk reduction with learning. If you build first, you are guessing. If you demo first, you are testing. If you sell first, you are validating. The earlier in that sequence you find out you are wrong, the cheaper it is to change direction. Find your equivalent of the room. It does not have to be a formal pitch event. It can be a WhatsApp group, a Slack community, a Skool community, a subreddit, a co-working space, or a founder programme like the [Cooper Project](https://shefftechparks.com/the-cooper-project). What matters is that the people in it will tell you the truth rather than be polite. Fill in the Lean Canvas before you build. Not because the canvas is sacred — you will change it within weeks — but because it forces you to write down your assumptions in a place where other people can challenge them. Build the demo, not the product. Show the path from problem to outcome. Make it real enough to be credible. Do not polish it. The rough edges are part of the honesty. Then put it in front of people and ask them to pay for it. If they will not, you have learned something valuable before it cost you six months. Andy's twelve minutes were not polished. They did not need to be. The room told us what we needed to hear. --- If you are building something and want to run it past an engineer before committing further, [try our app](https://studio.thehyperscale.io/early-access/) or book a free [Expert Session](/expert-sessions). Thirty minutes of structured feedback on your idea, your architecture, or your demo. - [What should go in an MVP? The founder's checklist for what makes the cut](https://hyperscale.consulting/blog/2026-what-should-go-in-an-mvp): A straightforward guide to deciding what makes the cut in your minimum viable product — and what to cut without guilt. Written for founders shipping their first SaaS without a technical background. My co-founder and I sat down a few weeks before our own launch to argue, politely, about what was actually going in the MVP. I was pushing hard for a gamified credits system. Instead of every new user getting a flat twenty credits at sign up, they would start with ten and earn more as they used the app to expand their idea. I liked it because it was clever. He liked it less, because it was not the thing anyone was paying us for. We went back and forth for the best part of an hour. In the end we cut it. The MVP shipped with a flat credit allocation and nothing else clever bolted on. The gamified version went onto an ideas board, where it has been joined since by a long list of suggestions from friends and other founders who have tried the product and told us what they wanted next. That argument is the one every founding team has, in some form, in the weeks before launch. The pull to add is enormous. The discipline to cut is what gets the thing out of the door. ## The short answer An MVP should contain the smallest thing a real person will pay for, plus the few unglamorous bits that make it safe to put in front of them. Nothing else earns a place yet. ## What actually belongs in the first version Think of an MVP the way a chef thinks about opening a small restaurant. You are not trying to print every dish you might ever cook. You are trying to serve one table well enough that they tell their friends. That gives you four categories. **The one thing the customer is paying for.** Name it in a single sentence. If you cannot, the MVP is not ready to scope — the thinking is. For a holiday-let booking tool, it might be "a host can take a paid booking from a guest without phoning their bank". For a compliance tool, it might be "an SME can produce a defensible record of who accessed what". Everything else in the build is in service of that sentence. **The path the customer walks to get there.** From the moment they land on the site or app to the moment they have the outcome they paid for. Every screen on that path earns its place. Every screen off it does not, yet. **The unglamorous safety bits.** Login that actually keeps people out of each other's accounts. A way to take payment that does not store card numbers on your own server. Backups. Basic logging so you know what happened when something breaks. A privacy notice that reflects what you are really doing with the data. None of this is exciting. All of it is what separates a product from a prototype. **The way you will hear from the first ten users.** An email address that gets read. A simple form. A Calendly link. Founders forget this one constantly and then wonder why the early feedback is silent. That is the MVP. Settings pages, profile photos, dark mode, in-app onboarding tours, integrations with tools your customer has not asked about — all of it can wait. ## What we see in the wild Two patterns we have watched cost founders months. The first is the founder who builds the admin panel before the product. By the time they show us what they have, there is a beautiful internal dashboard for managing users, resetting passwords, and viewing activity logs. What is missing is a clear answer to what a user actually does on day one. The admin panel got built first because the founder is a user of it — they know exactly what they need. Focus first on what a real, paying customer wants, unpredictable as that is, especially now that it is fast to add working features safely. We have done a version of this ourselves. In the first four months after starting our business, we built a security assessment tool to run our own client engagements. It was sharp, well-engineered, and made our work faster. At some point we looked at it and thought: we could offer this to clients directly. The problem was that it had been designed entirely around our workflow, not theirs. Adapting it for external use took longer than building it had. We had built the right tool for the wrong user. So be careful at the points where you pivot, and remember to cut back. The second is the founder who builds the second version of the product first. They had a genuinely interesting idea, spent a few weeks studying competitors, and ended up building the thing those competitors took three years and several rounds of funding to arrive at. The feature set is technically impressive. The differentiation is not there. Nothing connects back to a specific conversation with a real buyer — a person who said out loud that they needed this, that they had tried other things, and that none of them worked. The product is commercially silent because it was built for an imaginary customer shaped like the competitor's roadmap rather than a real one shaped by actual frustration. Both examples are from clever, hard-working founders. Both got to launch and found that the market did not care in the way they had expected. The fix is the same in both cases: go back to the sentence. One sentence, one user, one outcome they will pay for. Then check that what you are building is the path to that outcome, not the infrastructure around it. ## The 60-second self-check Read these five questions out loud. If any answer is no, the scope is still too big. 1. Can you describe what your MVP does in one sentence, without using the words "platform" or "solution"? 2. Could a stranger get from your landing page to the paid outcome in under five clicks? 3. If a customer signed up tonight, would their data be safe from other customers signing up tomorrow? 4. Do you know exactly how the first ten users will tell you what is wrong with it? 5. Is there at least one person who has said, in writing, that they would pay for this if it existed? If you answered yes to all five, stop scoping and start building. If you answered no to any of them, the next hour is better spent on that than on another feature. ## One last thing We launched without the gamified credits. The flat allocation went in, the ideas board filled up, and the feedback we got from the first paying users was not about credits at all — it was about things neither of us had thought to argue over. The clever loop I had fought for might still earn its place one day. It will do so on the back of evidence, not instinct. That is the whole point of an MVP. Not to be impressive. To be wrong quickly, in front of someone who is willing to pay you to be right. --- If you want to talk this through against your own scope, you can [run it past an engineer for free in 30 minutes](/expert-sessions) or [try our App Studio](https://studio.thehyperscale.io/early-access/) - [From Zero to Secure: Implementing CSP in Hours, Not Days](https://hyperscale.consulting/blog/2025-from-zero-to-secure-implementing-csp-in-hours-not-days): A comprehensive, step-by-step guide to implementing Content Security Policy across modern web platforms. From basic protection to advanced configurations, get your applications secured today. Content Security Policy implementation doesn't have to be complex or time-consuming. This guide will take you from vulnerability to protection in hours, not days, with practical tools, examples, and platform-specific instructions. This is **Part 2** of our CSP security series. If you missed it, start with [Part 1: Why 50% of Web Apps Are Vulnerable to XSS](/blog/2025-why-50-percent-of-web-apps-are-vulnerable-to-xss-and-yours-might-be-toos) to understand the business impact and risks. --- Quick navigation to help you find what you need: - [Understanding CSP Fundamentals & Best Practices](#understanding-csp-fundamentals-and-best-practices) - [Essential Tools to Streamline CSP Management](#essential-tools-to-streamline-csp-management) - [Quick Start: 5-Minute CSP Protection](#quick-start-5-minute-csp-protection) - [The Complete Implementation Process](#the-complete-implementation-process) - [Platform-Specific Setup](#step-4-platform-specific-implementation) - [Common Implementation Challenges](#common-implementation-challenges-and-solutions) - [Advanced Considerations for Scaling Startups](#advanced-considerations-for-scaling-startups) - [Troubleshooting Common Issues](#troubleshooting-common-issues) - [Conclusion & Key Resources](#conclusion) --- ## Understanding CSP Fundamentals and Best Practices Before diving into implementation, let's understand how Content Security Policy works, why it's so effective, and the best practices for using it. ### What CSP Does A Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution. CSP works by enabling server administrators to reduce or eliminate the vectors through which XSS and package sniffing can occur. This is done by specifying the domains that the browser should consider to be valid sources of executable scripts, form posts, iframes and ajax calls. A CSP compatible browser will then only load resources received from or send data to those allowed domains, ignoring all other sources. **Backward Compatibility**: CSP is fully backwards compatible with browsers that don't support it. Browsers that don't support CSP ignore it, functioning as usual, defaulting to the standard same-origin policy for web content. ### CSP Header Types - **`Content-Security-Policy`**: Enforces the defined source locations within the policy on compatible browsers - **`Content-Security-Policy-Report-Only`**: Does not enforce the defined source locations, but only logs to the console and sends reports when the policy is violated ### Core CSP Values The policy is built up of several [different directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives), each can be given a space-separated list of [values](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#values), of which the main ones are: - **`'none'`**: Won't allow loading of any resources - **`'self'`**: Only allow resources from the current origin - **`host`**: Only allow loading of resources from a specific host, with optional scheme, port, and path (e.g., `example.com`, `*.example.com`, `https://*.example.com:12`, `https://*.example.com:12/path/to/file.js`) - **`'nonce-*'`**: A cryptographic nonce (only used once) to allow scripts. The server must generate a unique nonce value each time it transmits a policy. It is critical to provide a nonce that cannot be guessed as bypassing a resource's policy is otherwise trivial ### Best Practices Implementing Content Security Policy involves careful consideration of best practices to strike a balance between security and functionality: **Security Principles:** - **Follow the Least Privilege Principle**: Always set the default source to `'none'` and only allow what is necessary - **Disable eval() and inline scripts**: Never allow `'unsafe-eval'` or `'unsafe-inline'` on `default-*` or `script-*` directives - **Define specific policies**: Avoid wildcards like `*`; be explicit about allowed sources - **Leverage nonces or hashes for inline scripts**: If inline scripts are necessary, use nonces or hashes to allowlist specific scripts **Implementation Strategy:** - **Start strict, loosen as needed**: Begin with a restrictive policy and only allow what you need - **Test in report-only mode**: Use `Content-Security-Policy-Report-Only` to test before enforcing - **Use environment variables or feature toggles**: Manage different CSPs for development, staging, and production to avoid breaking changes **Ongoing Management:** - **Set up reporting endpoints**: Configure `report-uri` or `report-to` to monitor violations - **Iterate and monitor**: CSP is not "set and forget"—review reports and update as your app evolves - **Employ upgrade-insecure-requests**: Automatically upgrade HTTP requests to HTTPS - **Implement Subresource Integrity (SRI)**: Use SRI for immutable scripts to prevent tampering **Remember**: CSP is not a substitute for secure development. Always follow secure coding practices such as those described in the [OWASP Cross-Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), and then deploy CSP on top of that as a bonus security layer. --- ## Essential Tools to Streamline CSP Management Now that you understand how CSP works, these tools will dramatically reduce implementation friction, transforming what could take days into hours. ### Professional CSP Management Platforms #### Report URI [report-uri.com](https://report-uri.com/products/content_security_policy) is a mature monitoring and policy-management platform focused on keeping your CSPs both effective and up-to-date, combining it with threat intelligence and other security features. **Key Features:** - **Centralized Reporting**: Aggregate CSP violations across all properties - **Analytics Dashboard**: Trend analysis and violation patterns - **Alert Systems**: Continuous detection of policy drift, unexpected resource load, or suspicious changes - **API Integration**: Programmatic access to violation data - **Compliance Support**: PCI DSS compliance support - **Multiple Tools**: - **CSP Analyser**: Discover all first- and third-party resources your site uses - **Script and Style Hasher for CSP**: Generate hashes for inline scripts and styles - **CSP Wizard**: Start with Report-Only mode, block everything then discover resources, import existing policies, tweak in UI - **CSP Builder Tool**: Intuitive user interface to build a CSP - **Real-time Monitoring/Reporting**: Drift monitoring with tools like Script Watch, Data Watch, Frame Watch, Policy Watch **Best for**: More useful for teams with significant traffic or complexity—if your site is simple or you don't expect many changes, you might not use all its value. #### CentralCSP - Learning Through Iteration [CentralCSP](https://centralcsp.com/) makes learning and managing CSP accessible through a low entry cost and data-driven scoring covering Security, Compliance, and Best Practices. Instead of just generating policies, it delivers actionable recommendations that explain why each directive matters and how to improve. With trend tracking over time, engineers can see the impact of changes, close gaps, and continuously strengthen their CSP. **Key Features for Learning:** - **Actionable Feedback**: Doesn't just tell you what's wrong—explains why and how to fix it - **Iterative Refinement**: Start with Report-Only mode, analyse violations, adjust policy, repeat - **Real-time Violation Monitoring**: See immediately how policy changes affect your application - **Compliance Scoring**: Understand how your CSP impacts security scores (BitSight, SecurityScorecard) - **Multiple Tools in One**: - **CSP Scanner**: Analyse live websites for vulnerabilities - **CSP Evaluator**: Assess policy strength and compliance - **CSP Builder**: Automated policy generation with best practices - **Violation Reporting**: Real-time monitoring dashboard **Best for**: Engineers seeking a deep understanding of CSP implementation, and teams aiming to scale their security practices cost-effectively laong with compliance alignment. #### Csper.io [csper.io](https://csper.io/) has a higher entry price point but provides added value through paid enterprise features alongside a suite of free standalone tools. It helps teams design, test, and refine policies with real-time validation and clear guidance, making CSP adoption more approachable. While its paid tier provides advanced features for larger teams (including role management, OAuth and SAML support, full API access, and Purchase Order or contract invoicing), the free tools give engineers hands-on experience similar to CentralCSP—ideal for experimenting, learning, and tightening security practices before scaling. **Key Features:** - **Automated Policy Generation**: Build new policies with a click based on previous reports - **Continuous Monitoring**: Real-time violation tracking across environments - **Team Collaboration**: Role management and OAuth/SAML support - **Integration Support**: Tiered pricing with full API access to dynamically generate projects, policies, reports and more - **Multiple Tools in One**: - **Report Collector**: Report endpoint, data aggregation, alerting and more - **Policy Generator**: Automatically generate new content security policies - **Policy Evaluator**: Evaluate existing content security policies - **Hasher**: Generate hashes for inline scripts and styles **Best for**: Teams and enterprises needing OAuth and SAML support. ### Web Analytics and Observability Tools with CSP Monitoring Modern web analytics and observability platforms now include built-in CSP violation monitoring, making it easier to track security issues alongside user behavior and application performance. This is not an exhaustive list check if the web analytics and observability provide built-in CSO monitoring or create a feature request. #### Datadog - CSP Reporting Integration [Datadog](https://www.datadoghq.com/blog/content-security-policy-reporting-with-datadog/) allows you to collect, monitor, and analyse CSP violation reports as part of your security and observability stack. You can forward CSP reports to Datadog using their HTTP API and visualize violations alongside other application and security metrics. **Best for**: Teams already using Datadog for observability and security monitoring who want to centralize CSP reporting. #### Honeycomb - CSP Reporting with OpenTelemetry [Honeycomb](https://www.honeycomb.io/blog/reporting-csp-errors-opentelemetry-collector) enables you to ingest and analyse CSP violation reports using OpenTelemetry Collector. This lets you correlate CSP errors with other application telemetry and observability data in Honeycomb's platform. **Best for**: Teams using Honeycomb and OpenTelemetry for distributed tracing and observability who want to include CSP errors in their analysis. #### GlitchTip (Sentry-Compatible) [GlitchTip](https://glitchtip.com/blog/2022-05-26-csp/) is an open-source, Sentry API compatible error tracking platform that includes CSP monitoring. **Key Features:** - **Sentry API Compatible**: Drop-in replacement for Sentry - **Self-Hosted**: Full data control and privacy - **CSP Violation Tracking**: Native support for CSP reports - **Easy Deployment**: Docker-based setup - **No Usage Limits**: Monitor unlimited violations #### PostHog - CSP Violation Dashboard [PostHog](https://posthog.com/templates/csp-dashboard) offers a dedicated CSP violation reports dashboard template as part of their product analytics platform. **Key Features:** - **Violation Trends**: Track daily violations over time with trend analysis - **Violated Directives**: Identify which CSP directives are being violated most frequently - **Affected URLs**: See which pages generate the most CSP violations - **Recent Violations**: Find the most recent violations for quick action - **Integrated Analytics**: Combine CSP monitoring with user analytics in one platform **Best for**: Teams already using PostHog or looking for combined analytics and security monitoring. **Setup**: Configure your CSP to send reports to PostHog's ingestion endpoint alongside your standard analytics tracking. #### Raygun - CSP Violation Reporting [Raygun](https://raygun.com/documentation/language-guides/browser-reporting/crash-reporting/reporting-api/) provides an endpoint for the browser to send CSP violation reports to, integrating CSP monitoring with their crash reporting and real user monitoring platform. **Best for**: Teams using Raygun for application performance monitoring who want to add CSP violation tracking. #### c/side - CSP Reporting and Security Analytics [c/side](https://docs.cside.dev/getting-started/setting-up-csp) provides a modern platform for collecting, analysing, and visualising CSP violation reports. It offers real-time dashboards, alerting, and deep analytics to help you quickly identify and respond to security issues surfaced by CSP. **Best for**: Teams looking for a dedicated, developer-friendly CSP reporting and analytics platform with easy setup and actionable insights. #### HTTPS Reporter - CSP Reporting and Security Analytics [HTTPS Reporter](https://httpschecker.net/guides/https-reporter) provides a lightweight way to collect and analyse CSP violation reports. It offers quick setup with clear guidance for adding a report endpoint and viewing violations, helping you detect and resolve policy issues faster. **Best for**: Teams wanting a low-friction, lightweight CSP reporting workflow to complement existing analytics and monitoring tools. ### Online CSP Tools and Generators #### CSP Builder Tools - **[CSP Builder](https://cspscan.com/)**: Interactive policy builder with real-time validation - **[CSP Generator](https://content-security-policy.com/)**: Step-by-step policy creation wizard - **[Mozilla CSP Guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)**: Comprehensive reference with examples ### Open-Source CSP Reporting Solutions For teams wanting full control and no external dependencies, several open-source solutions exist: **Deployment Options:** - Docker Compose for local/cloud hosting - Kubernetes for production environments - Integrates with existing Sentry configurations **Best for**: Teams wanting Sentry-like features without the cost or data sharing concerns. #### Framework-Specific Open Source Solutions **For Django (Python):** ```bash pip install django-csp-reports ``` [django-csp-reports](https://github.com/adamalton/django-csp-reports) - A lightweight Django app for handling browser CSP violation reports. **Setup:** ```python # settings.py INSTALLED_APPS = [ ... 'cspreports', ] # urls.py urlpatterns = [ path('csp-report/', include('cspreports.urls')), ] ``` **For Node.js/Express:** **Simple DIY Endpoint:** ```javascript const express = require('express'); const app = express(); app.post('/csp-report', express.json({ type: 'application/csp-report' }), (req, res) => { const violation = req.body['csp-report']; console.log('CSP Violation:', { blockedURI: violation['blocked-uri'], violatedDirective: violation['violated-directive'], originalPolicy: violation['original-policy'], documentURI: violation['document-uri'] }); // Log to file, database, or monitoring service // logToDatabase(violation); res.status(204).send(); }); ``` #### CSP Server with Elasticsearch [seek-oss/csp-server](https://github.com/seek-oss/csp-server) - Production-grade CSP reports server that forwards to Elasticsearch. **Features:** - Elasticsearch integration for searchable reports - Scalable architecture for high-volume sites - Filtering and aggregation capabilities - Visualisation with Kibana **For Go (Golang):** **Simple Handler:** ```go package main import ( "encoding/json" "log" "net/http" ) type CSPReport struct { BlockedURI string `json:"blocked-uri"` ViolatedDirective string `json:"violated-directive"` OriginalPolicy string `json:"original-policy"` DocumentURI string `json:"document-uri"` } type CSPReportWrapper struct { Report CSPReport `json:"csp-report"` } func cspReportHandler(w http.ResponseWriter, r *http.Request) { var wrapper CSPReportWrapper if err := json.NewDecoder(r.Body).Decode(&wrapper); err != nil { http.Error(w, err.Error(), http.StatusBadRequest) return } log.Printf("CSP Violation: %+v", wrapper.Report) // Send to logging service or database w.WriteHeader(http.StatusNoContent) } func main() { http.HandleFunc("/csp-report", cspReportHandler) log.Fatal(http.ListenAndServe(":8080", nil)) } ``` **For Next.js:** **API Route: `pages/api/csp-report.js`** ```javascript export default function handler(req, res) { if (req.method !== 'POST') { return res.status(405).json({ message: 'Method not allowed' }); } const violation = req.body['csp-report']; console.log('CSP Violation:', { blocked: violation['blocked-uri'], directive: violation['violated-directive'], page: violation['document-uri'] }); // Send to logging service (e.g., Vercel Analytics, PostHog, CentralCSP, etc.) res.status(204).end(); } export const config = { api: { bodyParser: { sizeLimit: '1mb', }, }, } ``` **For Spring Boot (Java):** ```java @RestController public class CSPReportController { @PostMapping(value = "/csp-report", consumes = "application/csp-report") public ResponseEntity handleCSPReport(@RequestBody String reportJson) { // Parse and log the report logger.info("CSP Violation: {}", reportJson); // Send to monitoring service // monitoringService.logViolation(reportJson); return ResponseEntity.noContent().build(); } } ``` **For Gatsby:** **gatsby-node.js:** ```javascript exports.onCreateDevServer = ({ app }) => { app.post('/csp-report', express.json({ type: 'application/csp-report' }), (req, res) => { console.log('CSP Violation:', req.body['csp-report']); res.status(204).send(); }); }; ``` ### Platform-Specific Integrations **Vercel:** - Use Next.js API routes (shown above) - No additional setup needed for hosting - Automatic HTTPS for report endpoints **Netlify:** - Use Netlify Functions for serverless reporting - Create `netlify/functions/csp-report.js`: ```javascript exports.handler = async (event) => { if (event.httpMethod !== 'POST') { return { statusCode: 405, body: 'Method Not Allowed' }; } const report = JSON.parse(event.body)['csp-report']; console.log('CSP Violation:', report); return { statusCode: 204, body: '' }; }; ``` ### Recommended Tool Workflow **For New Projects:** 1. **Start early with CSP Generator**: Auto-generate initial policy 2. **Validate with CSP Evaluator**: Check for security weaknesses 3. **Test with CSP Tester**: Verify application compatibility 4. **Set up reporting**: Choose tools based on your stack or budget 5. **Deploy with Report-Only**: Monitor real-world behavior 6. **Enforce and Monitor**: Switch to enforcement mode with continuous monitoring **For Existing Applications:** 1. **Use report only mode to scan or CSP Evaluator**: Assess current security posture on a small/low volume site 2. **Generate with a Builder**: Create policies based on actual usage 3. **Set up reporting endpoint**: Choose from options above 4. **Test Gradually**: Use Report-Only mode extensively (1-2 weeks) 5. **Refine Iteratively**: Adjust based on violation reports and actionable advice 6. **Scale monitoring**: Scale to other site --- ## Quick Start: 5-Minute CSP Protection For immediate basic protection following the least privilege principle: ```http Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; ``` This policy starts with maximum restrictions (`default-src 'none'`) and only allows what's explicitly needed. **What this policy does:** - Blocks all resources by default (`default-src 'none'`) - Allows scripts only from your own domain (`script-src 'self'`) - Allows styles only from your domain (`style-src 'self'`) - Allows images only from your domain (`img-src 'self'`) - Allows fonts only from your domain (`font-src 'self'`) - Allows network connections only to your domain (`connect-src 'self'`) - Blocks your site from being framed (`frame-ancestors 'none'`) **Note**: If you use inline styles or external CDNs, you'll need to adjust this policy (covered in the detailed implementation section). You can find additional examples in the [Content Security Policy (CSP) Quick Reference Guide](https://content-security-policy.com/examples/). Please note that these resources were created at a specific point in time — use them as a reference or starting point, and make sure to check for updates, validate configurations, and thoroughly test before applying them. --- ## The Complete Implementation Process ### Step 1: Audit Your Dependencies (15-30 minutes) Before configuring CSP, you need to understand what external resources your application uses. **Create a resource inventory:** 1. **CDNs and External Scripts** - Google Analytics, Google Fonts, Font Awesome - JavaScript libraries from CDNs (jQuery, React, etc.) - Payment processors (Stripe, PayPal) - Social media widgets 2. **Media and Assets** - Image hosting services (Cloudinary, AWS S3) - Video platforms (YouTube, Vimeo) - External stylesheets 3. **APIs and Data Sources** - REST APIs, GraphQL endpoints - Third-party data services - WebSocket connections **Use browser tools to discover resources:** ```javascript // Run this in your browser console to see all loaded resources Array.from(document.querySelectorAll('script[src], link[href], img[src]')) .map(el => new URL(el.src || el.href).origin) .filter((origin, index, arr) => arr.indexOf(origin) === index) .sort(); ``` ### Step 2: Choose Your CSP Strategy Based on the [OWASP CSP Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html), there are two main approaches: #### Option A: Strict CSP (Recommended) **Best for:** New applications or those you can modify **Benefits:** - Highest security level - Future-proof against new attack vectors - Easier to maintain long-term **Requirements:** - Ability to add nonces or hashes to scripts - Remove or refactor inline event handlers - Some development workflow changes #### Option B: Allowlist-based CSP **Best for:** Legacy applications or third-party heavy sites **Benefits:** - Easier initial implementation - Works with existing inline scripts - No code changes required **Limitations:** - More vulnerable to bypasses - Requires ongoing maintenance as dependencies change ### Step 3: Draft Your CSP Policy #### For Strict CSP (Recommended Approach) **Nonce-based Strict Policy:** ```http Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic'; object-src 'none'; base-uri 'none'; ``` **Hash-based Strict Policy:** ```http Content-Security-Policy: script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic'; object-src 'none'; base-uri 'none'; ``` #### For Allowlist-based CSP **E-commerce Site with Common Services:** ```http Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https: *.stripe.com; connect-src 'self' https://api.stripe.com https://www.google-analytics.com; frame-ancestors 'none'; ``` **Marketing Site with Analytics:** ```http Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://www.google-analytics.com; frame-ancestors 'none'; ``` **SaaS Application:** ```http Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' wss: https:; font-src 'self'; frame-ancestors 'none'; ``` ### Step 4: Platform-Specific Implementation #### Netlify (5-10 minutes, Beginner) Create a `_headers` file in your site's publish directory: ```http /* Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; X-Frame-Options: DENY X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin Permissions-Policy: camera=(), microphone=(), geolocation=() ``` [Watch: Netlify Headers Configuration Tutorial](https://youtu.be/LBIANHdBoUA) #### Vercel (5-10 minutes, Beginner) Add to your `vercel.json` file: ```json { "headers": [ { "source": "/(.*)", "headers": [ { "key": "Content-Security-Policy", "value": "default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';" }, { "key": "X-Frame-Options", "value": "DENY" }, { "key": "X-Content-Type-Options", "value": "nosniff" }, { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" } ] } ] } ``` #### AWS Amplify (10-15 minutes, Intermediate) Create a `customHttp.yml` file in your project root or configure in the Amplify Console: ```yaml customHeaders: - pattern: '**' headers: - key: 'Content-Security-Policy' value: "default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';" - key: 'X-Frame-Options' value: 'DENY' - key: 'X-Content-Type-Options' value: 'nosniff' - key: 'Referrer-Policy' value: 'strict-origin-when-cross-origin' ``` Or via the AWS Console: 1. Go to Amplify Console → Your App → App settings → Custom headers 2. Add headers configuration 3. Deploy changes #### Cloudflare Pages (10-15 minutes, Intermediate) Create a `_headers` file: ```http /* Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; X-Frame-Options: DENY X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin ``` #### Firebase Hosting (10-15 minutes, Intermediate) Add to your `firebase.json`: ```json { "hosting": { "headers": [ { "source": "**", "headers": [ { "key": "Content-Security-Policy", "value": "default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';" }, { "key": "X-Frame-Options", "value": "DENY" }, { "key": "X-Content-Type-Options", "value": "nosniff" } ] } ] } } ``` #### Azure Static Web Apps (10-20 minutes, Intermediate) Create a `staticwebapp.config.json`: ```json { "globalHeaders": { "Content-Security-Policy": "default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';", "X-Frame-Options": "DENY", "X-Content-Type-Options": "nosniff", "Referrer-Policy": "strict-origin-when-cross-origin" } } ``` #### Digital Ocean App Platform (15-30 minutes, Advanced) Currently requires using meta tags in your HTML or upgrading to a more flexible plan: ```html ``` **Note**: Meta tag CSP cannot set `frame-ancestors` directive. ### Step 5: Test Your Implementation (15-30 minutes) #### Use Content-Security-Policy-Report-Only First Before enforcing your policy, test it using the report-only mode: ```http Content-Security-Policy-Report-Only: your-policy-here; report-uri /csp-report-endpoint ``` This logs violations without blocking resources, allowing you to identify issues. #### Browser Testing 1. **Open Developer Tools** → Console tab 2. **Load your application** and navigate through key pages 3. **Look for CSP violations** - they'll appear as console errors 4. **Test critical functionality** - forms, payments, user interactions #### Automated Testing Tools **Online Scanners:** - [Mozilla Observatory](https://observatory.mozilla.org/) - Comprehensive security analysis - [Security Headers](https://securityheaders.com/) - Quick header verification - [CSP Evaluator](https://csp-evaluator.withgoogle.com/) - Google's CSP analysis tool **Browser Extensions:** There are browser extensions but I have intentonaly not included them due to lack of updates or reviews. #### Common Issues and Fixes **Problem**: Inline scripts blocked ```http Refused to execute inline script because it violates CSP directive 'script-src' ``` **Solution**: Move scripts to external files or use nonces/hashes **Problem**: Third-party widgets not loading ```http Refused to load script from 'https://widget.example.com' because it violates CSP ``` **Solution**: Add the domain to your `script-src` directive **Problem**: Images from user uploads not displaying ```http Refused to load image from 'https://user-uploads.com' because it violates CSP ``` **Solution**: Add the upload domain to `img-src` or use `https:` for all HTTPS images ### Step 6: Monitor and Maintain #### Set Up Violation Reporting For production monitoring, implement CSP reporting: ```http Content-Security-Policy: your-policy-here; report-uri https://your-domain.com/csp-report ``` **Simple Node.js Report Endpoint:** ```javascript app.post('/csp-report', express.json({ type: 'application/csp-report' }), (req, res) => { console.log('CSP Violation:', req.body); // Log to your monitoring system (CentralCSP, PostHog, GlitchTip, etc.) res.status(204).send(); }); ``` #### Regular Maintenance Tasks **Monthly Reviews:** - Check for new CSP violations in logs - Review and update third-party domains - Test policy after major application changes **Quarterly Assessments:** - Run security scans on updated policy - Review and tighten overly permissive directives - Update CSP as application evolves --- ## Common Implementation Challenges and Solutions ### Google Tag Manager Integration By default, Google Tag Manager provides inline scripts that need to be added to the page. However, these scripts will not work when using a CSP, as they will be disabled. The best approach is to use the npm module [react-gtm-module](https://www.npmjs.com/package/react-gtm-module), which will include the Google Tag Manager code in a way that complies with CSP. This can be achieved by using the following code snippet in your `_app.js` file: ```javascript import TagManager from "react-gtm-module" import {useEffect} from "react"; const tagManagerArgs = { gtmId: "GTM-NHFQHGV", } export default function App({ Component, pageProps }) { useEffect(() => { TagManager.initialize(tagManagerArgs) }, ) return ; } ``` ### Server Redirects and Form Actions When redirecting, the CSP checks the entire chain of sources, but browsers have differences in behavior for `form-action` redirects: - **Chrome/Safari**: Consider redirects when submitting forms potentially dangerous, since sensitive user data can be redirected to an attacker's domain. They block redirection if host-source (domain) not allowed in form-actions are in the redirect chain. - **Firefox**: Believes that server redirects are under the control of the page owner protected by CSP. During a redirect, it allows form submission even to third-party domains. **Practical Example**: If your service redirects customers from `a.b.com` to `c.b.com` and you have a CSP of: ```http Content-Security-Policy: form-action 'self' https:; ``` Firefox would allow the form to submit and redirect, but Chrome/Safari will not unless you have: ```http Content-Security-Policy: form-action 'self' https: c.b.com; ``` **Best Practice**: Always ensure any redirect domains coming from your server are added to the CSP. ### Browser Compatibility Considerations Be aware that not all browsers are fully compatible with CSP policies. Test your application across different browsers to ensure consistent behavior and adapt the policy if needed. Modern browsers have excellent CSP support, but legacy browsers may require fallback strategies. --- ## Advanced Considerations for Scaling Startups As highlighted in [LinkedIn's security engineering journey](https://www.linkedin.com/blog/engineering/security/enhancing-security-and-developer-productivity--linkedin-s-journe), implementing security practices early becomes exponentially more difficult as your team and application grow. **Key considerations for growing teams:** 1. **Development Workflow Integration**: Incorporate CSP testing into your CI/CD pipeline 2. **Team Training**: Ensure all developers understand CSP implications for new features 3. **Policy Management**: Use configuration management to keep CSP consistent across environments 4. **Monitoring Infrastructure**: Implement proper logging and alerting for CSP violations 5. **Security Review Process**: Include CSP impact in feature review checklists --- ## Troubleshooting Common Issues ### CSP Policy Too Restrictive **Symptoms:** Application features breaking, resources not loading **Solution:** Temporarily use `Content-Security-Policy-Report-Only` to identify needed permissions ### Policy Too Permissive **Symptoms:** CSP evaluator tools showing warnings **Solution:** Gradually tighten restrictions, starting with `default-src 'none'` and adding only necessary permissions ### Third-party Integrations Breaking **Symptoms:** Analytics, chat widgets, or payment forms not working **Solution:** Check integration documentation for required CSP directives ### Development vs Production Differences **Symptoms:** CSP works locally but fails in production **Solution:** Ensure your CSP accounts for production CDNs, monitoring tools, and deployment differences --- ## Next Steps: Beyond CSP Implementing CSP is an excellent start to your application security journey. Consider these additional security measures: ### Immediate Next Steps 1. **Implement other security headers**: `Strict-Transport-Security`, `X-Content-Type-Options` 2. **Enable Subresource Integrity (SRI)** for third-party resources 3. **Review and implement HTTPS everywhere** ### Strategic Security Planning 1. **Threat Modeling**: Use the [NCSC threat modelling guide](https://www.ncsc.gov.uk/collection/risk-management/threat-modelling) to identify broader security risks 2. **Security Testing**: Integrate security testing into your development workflow 3. **Incident Response Planning**: Prepare for security incidents before they happen ### Professional Security Assessment For comprehensive security evaluation, consider a professional [security assessment](/security-assessment). This is particularly valuable for: - Applications handling sensitive data - Growing startups preparing for compliance requirements - Teams wanting expert validation of their security posture --- ## Conclusion Content Security Policy implementation doesn't have to be daunting. With the right approach and tools, you can secure your application in hours, not days: 1. **Understand the fundamentals** - CSP mechanics, headers, and best practices 2. **Use the right tools** - Pick a tool chain that suits your team and organisation 3. **Start with basic protection** using the quick-start policy 4. **Audit your dependencies** to understand your requirements 5. **Choose the appropriate CSP strategy** for your application 6. **Implement platform-specific configuration** using our guides 7. **Test thoroughly** with Report-Only mode before enforcing 8. **Monitor and maintain** your policy over time The time investment is minimal compared to the protection gained. Your users, your data, and your business reputation are worth the effort. **Take action today**: Pick your platform, follow the configuration steps, and join the 50% of applications that properly protect their users against XSS attacks. --- ### Key Resources - **[OWASP CSP Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)** - Comprehensive technical reference - **[CentralCSP](https://centralcsp.com/docs/what-is-csp)** - Learning-focused CSP management platform - **[Report URI](https://www.youtube.com/watch?v=JBM18ERxw4c)** - Getting Started With CSP - **[CSP Video Tutorial](https://youtu.be/LBIANHdBoUA)** - Another Visual implementation guide - **[Mozilla Observatory](https://observatory.mozilla.org/)** - Test your security headers - **[CSP Evaluator](https://csp-evaluator.withgoogle.com/)** - Validate your policy - **[LinkedIn's Security Engineering Journey](https://www.linkedin.com/blog/engineering/security/enhancing-security-and-developer-productivity--linkedin-s-journe)** - Scaling security practices --- **About This Series:** - **Part 1**: [Why 50% of Web Apps Are Vulnerable to XSS](/blog/2025-why-50-percent-of-web-apps-are-vulnerable-to-xss-and-yours-might-be-toos) - Understanding risks and business impact - **Part 2**: Complete CSP implementation guide (this article) - [Why 50% of Web Apps Are Vulnerable to XSS (And Yours Might Be Too)](https://hyperscale.consulting/blog/2025-why-50-percent-of-web-apps-are-vulnerable-to-xss-and-yours-might-be-toos): Over half of web applications lack basic XSS protection through Content Security Policy. While modern platforms enable 5-minute deployments, they leave a critical security blind spot that could cost your business dearly. Over half of web applications either lack a Content Security Policy (CSP) or have a weak, ineffective policy that fails to protect users. If you've deployed to platforms like Amplify, Netlify, Cloudflare Pages, or used AI-powered tools like Lovable and Bolt.io, your site might be among them—regardless of how secure your code appears. Modern platforms enable deployment from concept to live site in minutes, but this speed creates a dangerous blind spot: **none of these platforms configure Content Security Policy by default**. They provide the infrastructure, but expect you to handle the security headers that protect against the web's most common attacks. ## The Hidden Cost of Missing CSP The financial impact varies significantly by company size and industry, but the pattern is consistent across all sectors: **For Small Businesses:** - **Immediate response**: 40-80 hours for incident containment, system patching, and immediate fixes - **Communication & compliance**: 20-40 hours for customer notifications, regulatory reporting, and legal consultations - **Forensics analysis**: 30-60 hours to understand breach scope, affected data, and attack vectors - **Total time cost**: 90-180 hours of focused work, often requiring external expertise - **Recovery period**: Weeks to months to fully restore operations and customer confidence **For Enterprise:** - Direct costs: Often exceed £1 million ([IBM reports an average of $4.88 million per breach](https://www.ibm.com/security/data-breach)) - Regulatory fines: GDPR penalties can reach 4% of annual turnover - Long-term impact: Years to rebuild reputation and customer confidence The severity depends on what attackers can access, but even small breaches can have outsized consequences for growing businesses. ## Understanding the Threat Landscape ### XSS: The Dominant Web Attack Vector Cross-site scripting (XSS) attacks have become the predominant threat facing web applications: - **Global impact**: [Research shows XSS attacks account for approximately 70% of all web application attacks globally](https://dl.acm.org/doi/10.1016/j.cosrev.2024.100634) - **Government systems**: According to the [HackerOne Government Bug Bounty Report](https://www.hackerone.com/report/government-edition-8th-annual-hacker-powered-security-report), XSS accounted for 40% of all valid vulnerability reports in government programs—double the cross-industry average - **Escalating complexity**: [Industry analysis](https://www.mdpi.com/2079-9292/14/6/1174) shows XSS attacks are becoming more sophisticated and harder to detect ### How Attacks Succeed Without CSP protection, successful attacks typically follow this pattern: 1. **Injection point**: Malicious scripts enter through form submissions, user-generated content, or compromised third-party dependencies 2. **Execution**: Scripts run with full privileges, accessing session tokens, personal data, and admin functions 3. **Exfiltration**: Sensitive data gets sent to attacker-controlled servers 4. **Persistence**: Attackers maintain access through stored payloads or session hijacking ### Beyond XSS: Additional Threats **Data Exfiltration**: According to the [2025 Verizon DBIR](https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf), 30% of breaches involved third-party vendors—twice last year's rate. The [IBM X-Force report](https://www.ibm.com/security/data-breach) found that nearly half of all cyberattacks resulted in data theft. **Clickjacking Evolution**: A significant new threat emerged in January 2025—["DoubleClickjacking" attacks](https://thehackernews.com/2025/01/new-doubleclickjacking-exploit-bypasses.html) that bypass traditional clickjacking protections by exploiting double-click timing gaps, enabling account takeovers. ## The Provider Reality Check Here's what major hosting platforms provide by default—and what they're missing: | Provider | Time to Configure | Difficulty | Default CSP | Headers Set | Headers Missing | Configuration | |----------|:-----------------:|:----------:|:-----------:|-------------|-----------------|---------------| | **Vercel** | 5-10 min | Beginner | ❌ None | `Strict-Transport-Security` | `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy` | [versel security headers](https://vercel.com/docs/headers/security-headers) | | **Amplify** | 10-15 min | Intermediate | ❌ None | None | `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy` | [amazon custom headers](https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.html) | | **Netlify** | 5-10 min | Beginner | ❌ None | `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options` | `Content-Security-Policy`, `Referrer-Policy`, `Permissions-Policy` | [netlify-headers](https://docs.netlify.com/manage/security/content-security-policy/) | | **Cloudflare** | 10-15 min | Intermediate | ❌ None | `NEL`, `Report-To` | `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy` | [cloudflare csp](https://content-security-policy.com/examples/cloudflare/) | | **Digital Ocean** | 15-30 min | Advanced | ❌ None | None | `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy` | [satatic site headers](https://ideas.digitalocean.com/app-platform/p/static-site-headers-and-routing) | | **Azure** | 10-20 min | Intermediate | ❌ None | `Strict-Transport-Security`, `Referrer-Policy`, `X-Content-Type-Options` | `Content-Security-Policy`, `X-Frame-Options`, `Permissions-Policy` | [csp header](https://learn.microsoft.com/en-us/answers/questions/1165304/how-to-set-content-security-policy-(csp)-header-no) | | **Firebase** | 10-15 min | Intermediate | ❌ None | `Strict-Transport-Security`, `X-Frame-Options`, `X-Content-Type-Options` | `Content-Security-Policy`, `Referrer-Policy`, `Permissions-Policy` | [firebase headers](https://firebase.google.com/docs/hosting/full-config#headers) | **Critical Finding**: Zero providers set a default CSP. The configuration burden falls entirely on developers, who often prioritize functionality over security headers. ## Why CSP Is Your Responsibility Cloud providers deliver robust, scalable infrastructure but cannot know your application's specific security requirements. Only you know: - Which external domains your application legitimately needs to load resources from - What inline scripts are necessary for your functionality - Which third-party services (analytics, payments, CDNs) your app integrates with - What level of security restrictions are appropriate for your use case This isn't a platform limitation—it's by design. Generic security policies would either be too restrictive (breaking functionality) or too permissive (providing no real protection). ## Content Security Policy: Your First Line of Defense CSP works by instructing browsers to only load resources from sources you explicitly approve. Think of it as a whitelist for your web application: **What CSP Prevents:** - **Cross-site scripting (XSS)**: Blocks unauthorized script execution - **Data injection attacks**: Prevents malicious content loading - **Clickjacking**: Controls how your site can be framed by other domains - **Mixed content vulnerabilities**: Enforces HTTPS-only resource loading **How CSP Works:** 1. Your server sends CSP headers with each page response 2. Browsers receive and enforce these policies automatically 3. Violations are blocked and can be reported for monitoring 4. Users are protected even if vulnerabilities exist in your code **Defense in Depth**: CSP provides crucial protection even for static sites. It can enforce [Subresource Integrity (SRI)](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) to protect against compromised third-party scripts, and creates multiple layers of security that make attacks significantly more difficult to execute. ## Assessing Your Risk Level **Higher Risk Scenarios** (CSP implementation strongly recommended): - Sites with user authentication or sensitive data handling - Applications with forms, comments, or user-generated content - Heavy integration with third-party scripts and services - E-commerce platforms or financial applications - Sites with client-side routing and dynamic content **Lower Risk Scenarios** (still beneficial): - Purely static sites with no user input - Marketing sites with minimal third-party integrations - Applications with robust input sanitization already implemented - Sites handling only non-sensitive, public information **For Scaling Startups**: As highlighted in [LinkedIn's security engineering journey](https://www.linkedin.com/blog/engineering/security/enhancing-security-and-developer-productivity--linkedin-s-journe), implementing security practices early—including CSP—becomes exponentially more difficult as your application and team grow. The time to implement is now, while your architecture is still manageable. ## The Implementation Reality The good news: implementing CSP isn't technically complex. Most developers can configure basic protection in under an hour. The challenge lies in understanding what your application needs and testing thoroughly to avoid breaking functionality. **Common Implementation Challenges:** - Identifying all external resource dependencies - Handling legacy code with inline scripts - Balancing security with third-party integrations - Testing across different browsers and use cases - Maintaining policies as applications evolve ## Next Steps: From Understanding to Implementation Understanding the problem is crucial, but implementation is where real protection begins. **Take Action This Week:** 1. **Audit your current security posture**: Use [Mozilla Observatory](https://observatory.mozilla.org/) or [Security Headers](https://securityheaders.com/) to check your applications 2. **Assess your risk level**: Consider your application type, user data sensitivity, and third-party integrations 3. **Prepare for implementation**: Review your external dependencies and hosting platform documentation **Coming Next Week**: Our comprehensive implementation guide, "From Zero to Secure: Implementing CSP in Hours, Not Days," **Can't Wait a Week?** For businesses needing immediate guidance, our [comprehensive security consultation](/security-assessment) can fast-track your CSP implementation and broader security strategy. Don't let a 30-minute security configuration become your business's most expensive oversight. Your users, your data, and your company's future depend on the security decisions you make today. --- ## About This Series This is **Part 1** of our comprehensive CSP security series: - **Part 1**: Understanding the risks and business impact (this article) - **Part 2**: Complete implementation guide with step-by-step instructions (publishing next week) --- ### References 1. [Comprehensive Analysis of Content Security Policy Effectiveness](https://dl.acm.org/doi/10.1016/j.cosrev.2024.100634) 2. [NDSS Symposium: Advanced CSP Research](https://www.ndss-symposium.org/ndss-paper/) 3. [HTTP Security Headers Analysis of Global Websites](https://arxiv.org/html/2410.14924v1) 4. [HackerOne 8th Annual Government Security Report](https://www.hackerone.com/report/government-edition-8th-annual-hacker-powered-security-report) 5. [Verizon 2025 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf) 6. [IBM Cost of Data Breach Report 2025](https://www.ibm.com/security/data-breach) 7. [DoubleClickjacking Attack Discovery](https://thehackernews.com/2025/01/new-doubleclickjacking-exploit-bypasses.html) 8. [XSS Attack Detection and Prevention Research](https://www.mdpi.com/2079-9292/14/6/1174) 9. [LinkedIn's Security Engineering Journey](https://www.linkedin.com/blog/engineering/security/enhancing-security-and-developer-productivity--linkedin-s-journe) 10. [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) - [Securing AWS Credentials on Engineer's Machines with macOS Secure Enclave](https://hyperscale.consulting/blog/2025-securing-aws-credentials-with-secure-enclave): Last week, I wrote about the lessons from the Nx package poisoning attack, where malicious package versions were published to npm, silently stealing cloud credential from any developer unlucky enough to download them. Amongst other things, the attack highlighted a problem in how we store and manage AWS credentials on development machines. Last week, [I wrote about](https://hyperscale.consulting/blog/2025-lessons-from-nx-package-poisoning-attack) the lessons from the Nx package poisoning attack, where malicious package versions were published to npm, silently stealing secrets - including cloud credentials - from any developer unlucky enough to download them. Amongst other things, the attack highlighted a problem in how we store and manage AWS credentials on development machines. That problem is the fact that the AWS CLI stores your credentials **unencrypted on disk**. Any process running as your user, such as a malicious npm package install, can access those credentials, steal them, and abuse them. In last week's post, I wrote about the many ways you can mitigate this threat. For example, using temporary credentials reduces the risk that stolen credentials can be used, and least privilege access can limit the damage that can be done with stolen credentials. But what if we could prevent unauthorised access to the credentials in the first place? That's why we've created [awseal](https://github.com/hyperscale-consulting/awseal) ## Hardware-Backed Security with awseal `awseal` is inspired by [Secretive](https://github.com/maxgoedjen/secretive). Secretive generates SSH keys in the Secure Enclave, a dedicated secure subsystem integrated into modern Apple devices. Keys generated in the Secure Enclave cannot be extracted, so they can't be stolen. Secure Enclave keys can also be configured to require biometric authentication before they can be used, meaning that no process can use your keys without your explicit permission. If you use Secretive as your SSH agent, you can be sure that your keys won't be stolen, and they can't be used without your approval. While you can't store AWS credentials in the Secure Enclave, you *can* generate elliptic curve key agreement keys for Hybrid Public Key Encryption (HPKE) scheme to encrypt and decrypt AWS credentials. Each time the credentials are decrypted, the Secure Enclave will request biometric authentication, preventing silent theft and reuse of credentials. Here's how it works with `awseal`: - **OIDC Credential Bootstrap:** AWS Identity Center (formerly AWS SSO) APIs are used to allow the user to authenticate with AWS over SSO. - **Seamless integration:** `awseal` integrates with the AWS CLI via the credential_process configuration option. - **Temporary Role Credentials**: `awseal` fetches role credentials as needed using the Identity Center GetRoleCredentials API. - **Credential Encryption**: Cached role and SSO credentials are encrypted using a Secure Enclave key. - **Biometric Access Control**: Every credential access requires Touch ID. ## What About Other Tools? Before building `awseal`, we looked at a couple of existing tools for securing AWS credentials on macOS: ### AWS Vault [AWS Vault](https://github.com/99designs/aws-vault) stores long-lived IAM user credentials in macOS Keychain and uses them to generate temporary session credentials. While it’s a solid tool, we ruled it out for two reasons: 1. It depends on long-lived IAM users, which AWS recommends avoiding. 2. It uses the password-protected Keychain, rather than Secure Enclave keys with biometric protection. ### AWS IAM Roles Anywhere Credential Helper [This helper](https://github.com/aws/rolesanywhere-credential-helper) allows workloads outside AWS to assume IAM roles using X.509 certificates. It’s powerful, but it requires standing up and managing a private CA, which adds operational overhead. And while it can integrate with macOS Keychain, it doesn’t use the Secure Enclave or enforce biometric authentication for access. In both cases, the missing piece for us was **hardware-backed protection with biometric enforcement**. That’s the gap awseal is designed to fill. ## Give It a Try Hardware-backed security with biometric access control makes it virtually impossible for malware to steal your AWS credentials. You'll obviously need a Mac with a Secure Enclave (most modern Macs have one) and, preferably, Touch ID for easy unlocking of your credentials. You'll also need to be using Identity Center to manage access to your AWS accounts. We've built on Identity Center to leverage it's support for OIDC authentication from the CLI, and it's support for multi-account access. Using Identity Center is an AWS best-practice, mainly for these reasons. `awseal` is built with auditability and security in mind. The entire implementation is a single Swift file, so it's easy to review, and every release is built with [SLSA provenance](https://slsa.dev/), to you can cryptographically verify the origins of the binaries. Give it a try and [let us know how you get on](https://github.com/hyperscale-consulting/awseal/discussions). - [Lessons From the Nx NPM Package Poisoning Attack: Securing Your AWS Environment Against Supply Chain Threats](https://hyperscale.consulting/blog/2025-lessons-from-nx-package-poisoning-attack): Last week, attackers poisoned the popular Nx build system on NPM with malicious versions that attempted to steal SSH keys, GitHub tokens, npm tokens, and AWS credentials. For many teams, that's a nightmare scenario. Let's look at what this attack tells us about securing AWS accounts against software supply chain threats. Last week, attackers poisoned the popular Nx build system on NPM with malicious versions that attempted to steal SSH keys, GitHub tokens, npm tokens, and AWS credentials. For many teams, that's a nightmare scenario. Let's look at what this attack tells us about securing AWS accounts against software supply chain threats. ## Package poisoning attacks These types of attack are not new of course. Attackers exploit the trust developers place in package repositories like NPM and PyPi. Code is downloaded and executed on the user's behalf with few restrictions - a perfect opportunity for abuse. And developers machines are particularly attractive, often containing credentials to code repositories and cloud environments. It's easy for these installation scripts to scan for important secrets and exfiltrate them to allow further attacks to be launched. These attacks are deployed via different mechanisms, including: - Compromised packages; attackers compromise legitimate maintainer accounts to inject malicious code into established packages. - Typosquatting; attackers upload packages to a central registry with very similar names to popular packages, hoping that a typo will result in a developer installing the malicious version. For example, the popular python `requests` library was targeted by various typosquatting packages, including one called `requesys`. - Namesquatting: similar to typosquatting, attackers take advantage of deleted projects or naming conventions to trick developers into downloading malicious packages. - Dependency confusion; typically refers to situations where attackers upload packages under company internal names, creating the risk that malicious packages are downloaded if repositories are not configured correctly. - AI package hallucination; sometimes an LLM will suggest a package that doesn't exist yet - so an attacker can upload a malicious package under that name to get victims to download it. Regardless of the mechanism, the result is malicious code running on a developers machine with all the privileges of the current user. ## Mitigating package poisoning threats How can you protect yourself from these attacks? Firstly, we want to reduce the risk of downloading malicious packages in the first place: - **Only use dependencies from projects that take security seriously.** The [OpenSSF Scorecard](https://github.com/ossf/scorecard) project exists to help open source consumers judge whether their dependencies are safe. Look for practices such as branch protection, code reviews, signed releases, and the use of MFA from package maintainers. - **Cryptographically pin package versions.** Pick a stable version and stick with it. Only upgrade for security fixes and for features you need. Avoid package declarations that automatically install the latest version. Instead, pin a specific version, and do it cryptographically if possible (e.g. via a sha256 hash). That way even if a package is compromised the installation will fail the cryptographic check. The malicious Nx versions were only available for about 8 hours - being selective about package upgrades reduces the risk of consuming malicious versions. - **Use trusted internal package repositories**, where packages are validated before they are used, rather than using arbitrary repositories on the internet. If you do this well, for example through a git-ops, PR-based approval workflow and automated scanning you can virtually eliminate certain types of attack without introducing unnecessary developer friction. Next, you'll want to limit the damage that can be caused if you *do* download a malicious package: - **No standing production access.** Separate production and non-production accounts and restrict developer access to production environments by eliminating standing access, requiring an approval process to allow access for specific tasks. - **Grant least privilege access.** Make sure that any configured credentials have only the access required. For example, if a certain project only requires Lambda, SQS and DynamoDB resources, don't grant privileges for EC2. Avoid admin policies, even for sandbox and dev accounts. Use IAM Access Analyzer to identify overly broad access. - **Use temporary credentials, not IAM Users.** We often find long-lived IAM user keys still lurking in developer machines. Instead, use temporary credentials and limit session duration as far as possible. If you're lucky, your credentials won't be active when an attacker attempts to use them. - **Implement permission guardrails.** Use permission boundaries to limit the maximum permissions an entity can have, and use Service Control Policies to explicitly deny dangerous operations so that if an attacker does manage to get hold of your credentials, they'll be limited to what they can do. And finally, you need to be able to detect and respond to any potential compromise to your AWS accounts. Monitor, alert and respond to unusual activity, - **Monitor and alert on unusual API activity from an IAM identity.** CloudTrail, CloudWatch and GuardDuty are all particularly useful here in identifying unusual activity that may indicate that an IAM identity has been compromised. - **Automate incident response to credential compromise.** If credentials have been compromised, speed and accuracy of the response is critical. The response can often be fully automated from detection through to eradication, especially for non-production accounts where there is no risk of production impact. For example, an indicator of credential compromise could be used to automatically trigger the revocation of all sessions associated with a given IAM Role, making the exfiltrated credentials useless while all existing users just need to re-authenticate. Where end-to-end automation isn't feasible, responses should still be automated and made available to incident responders to execute after analysis wherever possible, increasing the speed of response and reducing the chance for mistakes to be made. ## Protecting AWS Credentials on Developer Machines One of the reasons the Nx package poisoning attack was so dangerous is that it targeted **developer workstations**. These machines often hold the keys to the kingdom: plaintext AWS credentials, SSH keys, GitHub tokens, and other sensitive secrets. If a malicious package can read those files, it can exfiltrate them and immediately start abusing your cloud environment. The fact that AWS credentials are stored in plaintext on disk is a long-standing frustration of mine, especially given that most developer laptops today include dedicated secure hardware like Apple's Secure Enclave, designed to protect secrets with **hardware-backed, unextractable keys** and convenient access controls such as Touch ID. Inspired by the excellent [Secretive](https://github.com/maxgoedjen/secretive) project, I built a simple `credential_process` plugin for the AWS CLI that creates IAM Role credentials using AWS SSO OIDC tokens encrypted with a Secure Enclave–backed key. The result: - **No plaintext AWS credentials on disk.** - **Hardware-backed protection.** Credentials can only be decrypted with the Secure Enclave key. - **User-friendly access control.** Each decryption requires Touch ID authorisation, making it impossible for attackers to silently steal and reuse AWS credentials. It's just a prototype for now, we'll share more when it's ready to use. But this is the sort of low-friction, secure-by-design solution we get excited about at Hyperscale. ## Wrapping Up The Nx package poisoning attack is another reminder that software supply chain compromises aren't abstract — they're happening right now, and they target the weakest links: developer machines and poorly managed credentials. The good news is that you don't have to leave yourself exposed. By combining strong **preventive practices** (secure package workflows, least privilege, temporary credentials) with **protective measures on developer endpoints** (like Secure Enclave–backed keys), you can make these attacks far less damaging. At Hyperscale, we help teams put these protections into place without slowing developers down. Our approach is grounded in the [AWS Well-Architected Framework security best practices](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html), and we've helped organisations across industries strengthen their AWS environments against exactly these kinds of threats. If you'd like to understand how your AWS setup stacks up - or get help implementing practical protections against supply chain risks - [get in touch with us](/#contact). We'd be happy to start with [a no-obligation security posture review](/security-assessment?utm_source=direct&utm_medium=blog&utm_content=2025-lessons-from-nx-package-poisoning-attack). ## Legal - [Privacy Policy](https://hyperscale.consulting/privacy): Our commitment to your privacy and how we handle data. - [Terms of Service](https://hyperscale.consulting/terms): Terms that govern use of our website and services. - [About Us](https://hyperscale.consulting/about): 10+ years building production software. Now helping non-technical founders ship secure, scalable SaaS products. - [Survey](https://hyperscale.consulting/survey): Complete our security assessment survey to help us understand your security needs.