Dekrypt Security blog

Web app, PWA, or native app: how to choose

2026-10-13T00:00:00Z

"We need an app" is a common request. Sometimes that means a native app in the App Store and Google Play. Often a web app, or a progressive web app that people can install, does the same job for less money and less maintenance.

This post compares the three options plainly so you can choose, or at least ask the right questions.

The three options

Web app

A web app runs in the browser. Users open a URL. There is nothing to install and nothing to approve: you deploy a change and everyone has it immediately. One codebase works on phones, tablets and computers.

Progressive web app (PWA)

A PWA is a web app with extra abilities. MDN describes it as an app built with web platform technologies that, like a website, runs on multiple platforms from a single codebase and, like a platform-specific app, can be installed on the device, operate while offline and in the background, and integrate with the device and other installed apps.

Two pieces make that possible:

A web app manifest, a small JSON file describing the app's name, icons and how it should open when installed.
A service worker, a script that can cache files and respond when the network is unavailable. MDN notes that service workers are only available in secure contexts, meaning the site must be served over HTTPS (with localhost allowed for development).

A minimal manifest looks like this:

{
  "name": "Example Bookings",
  "short_name": "Bookings",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#0a0d12",
  "theme_color": "#0a0d12",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

The open-source project recall, is a PWA: it can be installed on iOS, Android and desktop from the browser, with no app store.

Native app

A native app is built for a specific platform, Android or iOS, using that platform's tools and distributed through its store. It has the fullest access to the device and the platform's look and feel. Android's application fundamentals and Apple's developer documentation describe the models each platform uses.

How they compare

	Web app	PWA	Native app
Install	None	Optional, from the browser	From an app store
Works offline	Usually not	Yes, if built for it	Yes
Codebases	One	One	One per platform (or a cross-platform framework)
Updates	Instant	Instant (service worker refreshes)	Through store review and user updates
Store listing	No	No (some stores allow PWAs; check each)	Yes
Device features	Browser APIs	Browser APIs	Full platform APIs
Store fees	None	None	Developer account fees apply

On the last row: Apple's Developer Program lists a $99 annual membership, and Google Play's developer account registration lists a US$25 one-time fee. Those are platform fees, before any development cost.

Questions that decide it

Who are your users, and how will they find you?

If people find you through search, links or a QR code, the web wins: one tap and they are using it. If people expect to search an app store, or your competitors are all in the store, a store listing may matter.

Does it need to work offline?

Field work, travel, poor connectivity. If yes, a web app alone won't do, but a PWA often will.

Does it need device features browsers don't offer?

Browsers can do a lot: camera access, location, notifications on many platforms, file access. But some background processing, deep OS integration and certain hardware access remain native-only or behave differently by platform. List the features you need, then check each against current browser support before deciding.

How often will it change?

Web apps and PWAs update instantly. Native apps go through store review for every update, and users may not install updates promptly. If you expect to change things weekly, that matters.

What is your budget for the next two years, not just the build?

Two native apps means two codebases to maintain, two sets of OS updates to track, and two store reviews. A PWA means one.

Is "it's in the App Store" a requirement on its own?

Sometimes it is, for credibility or because a client asked. Be aware that Apple's App Review Guidelines (section 4.2, Minimum Functionality) say an app should include features, content and UI that elevate it beyond a repackaged website. Wrapping a website in an app shell may be rejected.

Security differences

All three can be built securely, and all three can be built badly. A few differences are worth knowing:

The server is your security boundary, always. Whatever the client is, browser or native, never trust it. Check permissions and validate input on the server.
Secrets in native apps are not secret. App bundles can be downloaded and unpacked. An API key compiled into an app should be treated as public. The same is true for JavaScript in a web app.
Updates are a security feature. Web apps get fixes to every user instantly. A native app fix waits for review and for users to update; plan for supporting older versions.
Data on the device. Offline-capable apps store data locally. Store only what is needed, and use the platform's secure storage for anything sensitive, such as tokens.
HTTPS is required for PWAs anyway, because service workers need a secure context. Use it for everything.

Recommendation

For most small businesses and first versions:

Start with a web app, built mobile-first.
Make it a PWA if users come back often or need offline use.
Go native when there is a specific feature or distribution need the web can't meet, and you've confirmed it.

This order means you only pay for native development once you know you need it. If you start native and later find a PWA would have done, that money is hard to get back.

If you're not sure which fits your project, send it through the project brief and you get a straight answer, including "you don't need an app".

Sources

MDN Web Docs, Progressive web apps. Last verified 2026-10-13.
MDN Web Docs, Service Worker API. Last verified 2026-10-13.
Android Developers, Application fundamentals. Last verified 2026-10-13.
Apple Developer, Apple Developer Program. Last verified 2026-10-13.
Google Play Console Help, Create and set up your developer account. Last verified 2026-10-13.
Apple Developer, App Review Guidelines. Last verified 2026-10-13.

Securing a static site on Cloudflare Pages: what is done on this site

2026-10-13T00:00:00Z

A static site has a small attack surface: no database, no server-side sessions, no admin panel. That does not make it secure by default. Missing headers, third-party scripts and a careless contact form can all undo the advantage.

This post explains how I set up this site on Cloudflare Pages and why. The platform details are checked against Cloudflare's documentation as of the date below. The trust page shows the live header list, generated from the same file at build time.

The shape of the site

HTML, CSS, fonts and a little JavaScript, all generated ahead of time by a small build script and served from Cloudflare Pages.
One server-side component: a Pages Function at /api/contact that turns form submissions into an email.
No third-party requests at all. No CDN-hosted libraries, web fonts, analytics or embeds.

The last point matters most. Every external script is code you did not write running with full access to your page. The simplest way to manage that risk is not to have any.

Security headers with _headers

Cloudflare Pages reads a plain-text file called _headers from the build output directory and attaches the headers it lists to matching static responses. The Pages headers documentation describes the format: a URL pattern on one line, then indented Name: value lines. You may define up to 100 header rules.

The rule for every path:

/*
  Content-Security-Policy: default-src 'self'; img-src 'self' data:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self'; base-uri 'none'; object-src 'none'; form-action 'self'; frame-ancestors 'none'; worker-src 'self'
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  Cross-Origin-Opener-Policy: same-origin

What each does:

Header	Purpose
`Content-Security-Policy`	Only load resources from this origin. No inline script or style, no plugins, no `<base>` tag, forms post only here, nobody may frame the site, and background workers may load only from this origin. See MDN's CSP reference.
`X-Content-Type-Options: nosniff`	Browsers must respect the declared content type instead of guessing.
`X-Frame-Options: DENY`	Older browsers' version of `frame-ancestors 'none'`.
`Referrer-Policy`	Send only the origin, not the full URL, to other sites.
`Permissions-Policy`	Disable camera, microphone, geolocation and payment APIs the site never uses.
`Strict-Transport-Security`	Browsers use HTTPS only, for a year, including subdomains.
`Cross-Origin-Opener-Policy`	Isolate this site's browsing context from pages that open it.

Two cautions on HSTS: includeSubDomains applies to every subdomain, so make sure they all serve HTTPS first. And once browsers have seen the header, removing it does not undo it until max-age passes.

The CSP has to be true

A strict CSP only works if the site obeys it. That meant rules from the start:

No inline <script>, except JSON-LD structured data, which browsers do not execute.
No inline <style>, no style= attributes, no onclick= handlers.
Fonts self-hosted. Icons as inline SVG.
The theme toggle and tools are external JavaScript files from the same origin.

The test suite loads every page in a headless browser and fails on any CSP violation or any request to another host.

Caching

HTML is sent with no-cache, so browsers revalidate and see updates immediately. CSS and JavaScript files have a content hash in their names and are cached for a year, because a changed file gets a new name. Fonts are also cached for a year.

The contact form

The form posts JSON to /api/contact, a Pages Function. Important detail from the documentation: **custom headers in _headers are not applied to responses generated by Pages Functions.** The function sets its own response headers.

Limit where Functions run

By default, a Functions project can invoke Functions on every route. A _routes.json file controls this. The Pages Functions routing documentation describes it: a version (currently 1), plus include and exclude lists, with no more than 100 rules combined and no more than 100 characters each. Mine includes only /api/*, so every other request is served as a static file without running code.

{
  "version": 1,
  "include": ["/api/*"],
  "exclude": []
}

What the function checks

The handler treats every request as untrusted:

POST only; anything else gets 405.
Content-Type: application/json only; anything else gets 415.
A small body size limit.
The Origin header must be this site.
A strict schema: known fields only, length limits, a valid email address.
A hidden honeypot field. If it is filled in, the request is accepted and silently discarded.
Control characters and line breaks stripped from fields that go into email headers, which prevents header injection.
The email is sent as plain text, never HTML.
Errors are generic. Message contents are never logged.

The API key for the email provider lives in an environment variable in Cloudflare, not in the repository. If any required variable is missing, the function returns 503 and the page shows the email address instead.

Rate limiting

Abuse protection belongs in front of the function. Cloudflare's WAF rate-limiting rules can limit requests to /api/contact per IP. Configure this in the dashboard.

Redirects

Pages also reads a _redirects file. The redirects documentation limits it to 2,000 static and 100 dynamic redirects. I use only a handful, all to fixed paths on this domain, so there is no open-redirect risk from user-controlled destinations.

security.txt

I publish /.well-known/security.txt per RFC 9116, with an Expires date set by the build script. Some hosts do not serve dot-directories by default, so check the live URL after deploying.

What this does not cover

Your Cloudflare account. Use a strong, unique password and multi-factor authentication. Anyone with that account can change everything above.
Your DNS and registrar accounts, for the same reason.
Your build pipeline. If CI can deploy, protect who can change it.

A checklist for your own static site

Remove third-party scripts you do not need. Self-host the rest.
Write a _headers file with a CSP that matches what the site actually loads.
Test it in report-only mode, then enforce.
If you use Functions, restrict them with _routes.json and set headers in the function.
Validate every form input server-side, and rate-limit.
Publish security.txt.
Check the live headers after every deploy.

Sources

Cloudflare Docs, Pages: Headers. Last verified 2026-10-13.
Cloudflare Docs, Pages Functions: Routing. Last verified 2026-10-13.
Cloudflare Docs, Pages: Redirects. Last verified 2026-10-13.
IETF, RFC 9116. Last verified 2026-10-13.
W3C, Content Security Policy Level 3. Last verified 2026-10-13.
MDN Web Docs, Content-Security-Policy. Last verified 2026-10-13.

Securing a small business website: headers, forms, and updates

2026-10-13T00:00:00Z

A small business website is rarely attacked because someone chose you. It is attacked because automated tools scan the whole internet for common weaknesses, and your site was on the list. That is good news: protecting against automated, opportunistic attacks mostly means getting a few basics right.

This post covers three of them. Security headers, which take minutes. Forms, which are where most input from strangers arrives. And updates, which are where most small sites actually fail.

1. Security headers

Security headers are instructions your server sends to the browser with every page. They cost nothing to add and block several classes of attack outright. The OWASP HTTP Headers Cheat Sheet is the best single reference.

The headers to set

Header	Suggested value	What it does
`Strict-Transport-Security`	`max-age=31536000; includeSubDomains`	Browsers always use HTTPS for your site.
`Content-Security-Policy`	Start with `default-src 'self'` and adjust	Limits where scripts, styles and other resources may load from.
`X-Content-Type-Options`	`nosniff`	Stops browsers guessing file types.
`Referrer-Policy`	`strict-origin-when-cross-origin`	Doesn't leak full URLs to other sites.
`Permissions-Policy`	`camera=(), microphone=(), geolocation=()`	Turns off browser features you don't use.
`X-Frame-Options`	`DENY` (or CSP `frame-ancestors 'none'`)	Stops other sites framing yours (clickjacking).

HSTS, carefully

Strict-Transport-Security tells browsers to use HTTPS only. MDN's HSTS page explains why it matters: without it, the very first visit over plain http:// can be intercepted before your redirect to HTTPS happens. Two cautions. includeSubDomains applies to every subdomain, so make sure they all work over HTTPS first. And once browsers have seen the header, they will refuse plain HTTP until max-age runs out, so start with a short value (say, max-age=300) and increase it once you are sure.

CSP, gradually

A Content-Security-Policy is the most powerful header and the one most likely to break something, especially on sites with plugins, chat widgets or embedded videos. Deploy it first as Content-Security-Policy-Report-Only, which reports problems in the browser console without blocking anything, fix what it reports, then switch to enforcing.

Headers to remove

OWASP recommends removing X-Powered-By, which tells attackers which technology you run. It also recommends not setting the old X-XSS-Protection header, because in some cases it can create vulnerabilities in otherwise safe sites; use a CSP instead.

Check your headers

You can see your headers in your browser's developer tools (Network tab, click the page, look at Response Headers). Or use this short Python script, which needs only the standard library:

import sys
import urllib.request

EXPECTED = [
    "content-security-policy",
    "strict-transport-security",
    "x-content-type-options",
    "referrer-policy",
    "permissions-policy",
]
REMOVE = ["x-powered-by", "x-xss-protection"]

url = sys.argv[1]
req = urllib.request.Request(url, method="HEAD")
with urllib.request.urlopen(req, timeout=10) as resp:
    headers = {k.lower(): v for k, v in resp.headers.items()}

for name in EXPECTED:
    print(("OK      " if name in headers else "MISSING ") + name)
for name in REMOVE:
    if name in headers:
        print("REMOVE  " + name + ": " + headers[name])

Save it as check_headers.py and run python3 check_headers.py https://yoursite.example/. Every line should say OK, and no REMOVE lines should appear. The security headers generator writes the configuration for Cloudflare Pages, nginx, Apache or Caddy.

2. Forms

Every form on your site, whether contact, booking, newsletter or login, accepts input from anyone on the internet. Treat that input as untrusted.

Validate on the server

The OWASP Input Validation Cheat Sheet is blunt: client-side validation is bypassable; use it for immediate feedback only. Whatever checks you put in the browser, repeat them on the server:

Accept only the fields you expect. Reject anything else.
Set a maximum length for every field.
Check formats: a real-looking email address, a date that is a date.
Strip line breaks from anything that ends up in an email header, such as the subject or "reply-to". Otherwise someone can inject extra headers and use your form to send spam.
Send notification emails as plain text, not HTML built from user input.

Stop spam without annoying people

A honeypot field: a field hidden from people but visible to simple bots. If it is filled in, quietly discard the message.
Rate limiting: limit how many submissions one address can make per minute. Most hosts and CDNs offer this.
A challenge if spam continues. Cloudflare Turnstile, for example, is described by Cloudflare as a CAPTCHA alternative that can work without showing visitors a puzzle.

Don't collect what you don't need

Every field you collect is data you have to protect. A contact form needs a name, an email address and a message. Ask for more only if you will use it.

Keep secrets out of the page

API keys for email services, payment providers or databases belong on the server, in environment variables. Never in JavaScript sent to the browser, and never committed to your code repository.

3. Updates

For sites built on a CMS such as WordPress, outdated software is the most common way in. Automated tools look for known-vulnerable versions of the CMS, its plugins and its themes.

CISA publishes a Known Exploited Vulnerabilities catalog, which it describes as the authoritative source of vulnerabilities that have been exploited in the wild. You don't need to read it daily, but it shows why patching matters: these are flaws attackers are already using.

A routine that works

Turn on automatic updates for minor and security releases, if your platform supports them.
Check weekly for plugin and theme updates. Apply them after taking a backup.
Remove what you don't use. A deactivated plugin can still be vulnerable if its files are on the server. Delete it.
Choose fewer, well-maintained plugins. Check when a plugin was last updated before installing it.
Keep the server current too: PHP or Node.js versions, and the operating system, if you manage it.
Back up before updating, and test that you can restore.

Or avoid the problem

A static site, pre-built HTML files with no server-side code or database, has far less to update. If your site is mostly information pages, it may not need a CMS at all. I wrote about how this site is set up on Cloudflare Pages.

Accounts: the fourth basic

None of this helps if someone logs in to your hosting, domain registrar or CMS admin with a stolen password. Use a password manager, a unique password and two-factor authentication on each of those accounts. See personal security you can finish in a weekend.

A one-page checklist

HTTPS everywhere, with HSTS.
Security headers set, and checked with the script above.
A CSP, tested in report-only mode first.
X-Powered-By removed.
Every form validated on the server, with length limits and a honeypot.
Rate limiting on form endpoints.
No secrets in front-end code.
Automatic updates on; weekly check for the rest.
Unused plugins and themes deleted.
2FA on hosting, domain and admin accounts.

This won't stop a determined, targeted attacker. It will stop most of the automated attacks small business sites actually face.

Sources

OWASP, HTTP Headers Cheat Sheet. Last verified 2026-10-13.
MDN Web Docs, Strict-Transport-Security. Last verified 2026-10-13.
OWASP, Input Validation Cheat Sheet. Last verified 2026-10-13.
Cloudflare Docs, Turnstile. Last verified 2026-10-13.
CISA, Known Exploited Vulnerabilities Catalog. Last verified 2026-10-13.

Personal security you can finish in a weekend: passwords, 2FA, backups

2026-10-13T00:00:00Z

Most people know they should use a password manager, turn on two-factor authentication and back up their files. Few do all three, because it feels like a big project. It isn't. Split into steps, it fits into a weekend, and each step makes you safer on its own.

This is the plan I'd walk you through. It is advice for individuals and small teams, not a guarantee: it lowers your risk a lot, but it cannot remove it.

Saturday morning: a password manager

Why

Reused passwords are the main problem. When one site leaks, attackers try the same email and password everywhere else. The fix is a different password for every account, which is only practical with a password manager.

US guidance agrees on what makes a password good. NIST's digital identity guidelines, SP 800-63B, tell services not to impose composition rules (such as "one symbol, one number") and not to force periodic password changes, only to require a change when there is evidence of compromise. Length and randomness matter more. CISA's advice to the public, Use Strong Passwords, is: long (at least 16 characters), random, and unique, created with a password manager.

Steps

Pick a password manager. Use a well-known one that works on all your devices. The one built into your phone or browser is fine to start with if it syncs everywhere you need it.
Create one strong master password. This is the one password you remember. A passphrase of several random words is easier to type and remember than a jumble of symbols. My password and passphrase generator creates one in your browser; nothing leaves your device.
Write the master password down once and keep the paper somewhere safe at home until you have memorised it. A paper note in a drawer is far safer than a reused password.
Install the manager on your phone and computer and turn on autofill.

Change the important passwords first

Do not try to change every account today. Start with the accounts that unlock the others:

Your main email account. Whoever controls it can reset almost every other password.
Your phone's account (Apple ID or Google account).
Banking and payment apps.
Cloud storage, where your photos and documents live.
Work accounts and anything with admin rights.

For each, let the manager generate a new password, save it, and log in again to check it works. Change the rest as you log in to them over the following weeks.

Saturday afternoon: two-factor authentication

Why

Two-factor (or multi-factor) authentication means a stolen password is not enough on its own. CISA's MFA guidance lists the common forms, from text-message codes through authenticator apps to phishing-resistant methods, and recommends turning it on first for email, financial services, social media, and online stores.

Which kind

From weakest to strongest, roughly:

Method	Notes
SMS or voice code	Much better than nothing. Can be intercepted or redirected if someone takes over your number.
Authenticator app	Codes generated on your phone. A good default.
Push approval	Convenient. Only approve prompts you started yourself.
Passkey or security key	Phishing-resistant: it will not work on a fake site. Best where supported.

Use the strongest method each service offers that you can manage reliably.

Steps

Turn on 2FA for the same priority list: email, phone account, banking, cloud storage, work.
Save the recovery codes each service gives you. Store them in your password manager, and print the codes for your main email account and keep them with your master password note.
If you use an authenticator app, check whether it can back up to a new phone. If it can't, losing your phone means using recovery codes for every account.

Sunday: backups

Why

Phones get lost, laptops die, and ransomware encrypts files. A backup is the only thing that fixes all three.

A simple rule from CISA's paper on data backup options is 3-2-1: keep 3 copies of important files (the original and 2 backups), on 2 different types of media, with 1 copy stored offsite. The UK's NCSC backup guidance puts the scope simply: back up anything that would inconvenience you if you could no longer access it.

A practical 3-2-1 for one person

Original: your phone and laptop.
Backup 1, cloud: turn on your phone's cloud backup and a cloud sync for your documents and photos. It runs automatically.
Backup 2, offline: an external drive. Copy your important folders to it once a month, then unplug it. A drive that is always connected can be encrypted by ransomware along with everything else.

The offline drive at home and the cloud copy elsewhere give you the "1 offsite".

Test a restore

A backup you have never restored is a hope, not a backup. Pick one file from each backup and open it on another device. If you can't, fix it now.

For files you copy to a drive, you can check they arrived intact by comparing checksums. On Linux or macOS:

cd ~/Documents
find . -type f -exec shasum -a 256 {} + | sort -k 2 > /tmp/originals.txt
cd /path/to/backup/Documents
find . -type f -exec shasum -a 256 {} + | sort -k 2 > /tmp/backup.txt
diff /tmp/originals.txt /tmp/backup.txt && echo "Backup matches"

No output from diff and "Backup matches" means every file is identical. The hash and file checksum tool does the same for single files in your browser.

Sunday evening: quick wins

If you have time left:

Turn on automatic updates on your phone, computer and browser.
Lock screens with a PIN or biometrics.
Remove apps and browser extensions you no longer use.
Check account recovery details: make sure the recovery phone number and email on your main accounts are current.

What this does not cover

This setup protects against the most common problems: reused passwords, stolen passwords, and lost files. It does not protect against a targeted attacker, a compromised device, or every scam. If you think an account has already been taken over, use the service's official account recovery process first.

If you would like help doing this on your own devices, that is what the personal security setup sessions are for.

Sources

NIST, SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management. Last verified 2026-10-13.
CISA, Use Strong Passwords. Last verified 2026-10-13.
CISA, More than a Password (MFA). Last verified 2026-10-13.
CISA, Data Backup Options (PDF). Last verified 2026-10-13.
NCSC (UK), Back up your most important data. Last verified 2026-10-13.