DEV Community: az hala

Designing Production-Grade Mobile Apps: Architecture, State, Offline-First, and Failure Handling

az hala — Thu, 24 Sep 2026 13:35:58 +0000

Designing Production-Grade Mobile Apps

A mobile application can look simple from the outside while hiding a surprisingly complex distributed system underneath.

A user taps a button. The UI updates. A request is sent. A server validates a token, writes data to a database, triggers a background job, and returns a response. The client then has to decide what to render if the network is slow, the request times out, the token expires, the process is killed, the device goes offline, or the user taps the same action twice.

That is the real engineering problem behind production mobile applications.

This article presents a failure-first approach to mobile application design. The goal is not to pick a trendy framework or produce another screen-by-screen UI tutorial. The goal is to define boundaries, state transitions, data ownership, networking behavior, and recovery strategies that keep a mobile codebase understandable as the product grows.

The examples are framework-neutral, but the principles map well to Kotlin/Android, Swift/iOS, Flutter, and React Native architectures.

1. Start With a System Model, Not a Screen List

A common mistake is to begin with a list of screens:

Login
Home
Profile
Orders
Checkout
Settings

That is useful for a design review, but insufficient for engineering.

Before implementation, define the system boundaries:

+----------------------- Mobile Client -----------------------+
| UI -> State -> Use Cases -> Repositories -> Data Sources    |
|             |                  |                            |
|             |                  +--> Local DB / Cache        |
|             +----------------------> Network Client         |
+-------------------------------------------------------------+
                         |
                         v
                 API / Backend Services
                         |
             +-----------+-----------+
             |                       |
          Database              External APIs

The important question is not only "What screens do we have?" It is:

Which layer owns each decision, and what happens when the expected dependency is unavailable?

For example, a UI component should not decide how a token is refreshed. A network interceptor should not decide whether a user should see an empty state. A repository should not know how a composable or view controller is rendered.

Clear ownership reduces accidental coupling.

2. Use Explicit Architectural Boundaries

A practical structure for a growing application is:

presentation/
    screens/
    viewmodels/
    ui-state/

domain/
    entities/
    usecases/
    repositories/

data/
    api/
    database/
    cache/
    repository-impl/

core/
    networking/
    auth/
    logging/
    analytics/
    errors/

The exact folder names do not matter. The dependency direction does.

A useful rule is:

Presentation -> Domain -> Data

The domain layer should not depend on HTTP clients, SQLite implementations, Android Activities, SwiftUI views, or other framework details.

A repository interface might look like this:

interface OrderRepository {
    suspend fun getOrders(forceRefresh: Boolean = false): Result<List<Order>>
    suspend fun submitOrder(command: SubmitOrder): Result<Order>
}

The UI calls a use case rather than constructing HTTP requests directly:

class SubmitOrderUseCase(
    private val repository: OrderRepository
) {
    suspend operator fun invoke(command: SubmitOrder): Result<Order> {
        return repository.submitOrder(command)
    }
}

This separation pays off when the same business operation later needs to work with a cache, a queue, a mock API, or a second client.

3. Treat UI State as a State Machine

Many production bugs come from UI state being represented by unrelated booleans.

This pattern is fragile:

var isLoading = false
var hasError = false
var isEmpty = false
var hasData = false

It allows impossible combinations such as:

isLoading = true
hasError = true
hasData = true

Instead, model meaningful states explicitly:

sealed interface OrdersUiState {
    data object Loading : OrdersUiState

    data class Content(
        val orders: List<Order>,
        val isRefreshing: Boolean = false
    ) : OrdersUiState

    data class Empty(
        val canRetry: Boolean = true
    ) : OrdersUiState

    data class Error(
        val message: String,
        val canRetry: Boolean = true
    ) : OrdersUiState
}

Now the screen has a finite set of states.

That matters because a real mobile client has more than a happy path:

Cold Start
   |
   v
Loading -----> Error
   |
   v
Content -----> Refreshing -----> Content
   |
   +---------> Offline

An explicit state machine is much easier to test than a collection of flags.

4. Separate Remote State, Local State, and UI State

A useful distinction is:

Remote state: what the server currently knows.

Local state: what is persisted on the device.

UI state: what the current screen needs to render.

For example, a profile record may exist in a local database for 30 minutes, while the UI only cares whether the record is available and whether a refresh is running.

Do not make UI state the database schema.

Instead:

Remote DTO
    |
    v
Mapper
    |
    v
Domain Model
    |
    v
UI Model

This gives the client freedom to change API contracts without forcing every screen to change at the same time.

5. Design Networking Around Failure, Not Just HTTP 200

A request can fail in many ways:

DNS failure
TCP connection failure
TLS failure
timeout
HTTP 401
HTTP 403
HTTP 404
HTTP 409
HTTP 422
HTTP 429
HTTP 500
HTTP 503
malformed response
partial response
client cancellation

Treating every non-200 response as Exception("Request failed") destroys useful information.

Use a normalized error model:

sealed interface NetworkError {
    data object NoConnection : NetworkError
    data object Timeout : NetworkError
    data object Unauthorized : NetworkError
    data object Forbidden : NetworkError
    data object NotFound : NetworkError
    data object Conflict : NetworkError
    data object RateLimited : NetworkError
    data object ServerUnavailable : NetworkError
    data class InvalidResponse(val code: Int?) : NetworkError
}

Then map transport errors into domain-safe errors before they reach the UI.

The screen should not need to know what SocketTimeoutException means.

6. Token Refresh Needs Concurrency Control

A particularly subtle problem occurs when several API calls receive 401 Unauthorized at nearly the same time.

A naive interceptor may start a refresh for every request:

Request A -> 401 -> refresh token
Request B -> 401 -> refresh token
Request C -> 401 -> refresh token

That can create race conditions.

Instead, make token refresh a single-flight operation:

A ----\
B -----+----> refreshOnce() ----> new token
C ----/

Conceptually:

private var refreshInFlight: Deferred<Token>? = null

suspend fun getFreshToken(): Token {
    val existing = refreshInFlight
    if (existing != null) return existing.await()

    val created = scope.async(start = CoroutineStart.LAZY) {
        authApi.refresh(refreshToken)
    }

    refreshInFlight = created

    return try {
        created.await()
    } finally {
        refreshInFlight = null
    }
}

The implementation varies by platform, but the invariant should remain: concurrent unauthorized requests must coordinate around one refresh operation.

7. Retry Is a Policy, Not a Reflex

Retrying everything is dangerous.

This is usually acceptable for idempotent reads:

GET /products
GET /profile

It is much more dangerous for a mutation:

POST /payments
POST /orders
POST /transfers

Imagine the client times out after the server successfully processes the payment. The client sees a timeout and retries. Without idempotency, the server may process the same operation twice.

For important mutations, send an idempotency key:

POST /orders
Idempotency-Key: 5f3e4d1c-...

The backend stores the result associated with that key and returns the same logical result for a duplicate request.

A retry policy should consider:

Is the operation idempotent?
Was there a transport failure or a definitive business failure?
Is the response retryable?
Has the maximum attempt count been reached?
Would another attempt create a duplicate side effect?

8. Use Exponential Backoff With Jitter

If 5,000 clients receive a temporary server failure and all retry exactly two seconds later, the server can receive another synchronized spike.

A more robust delay is approximately:

backoff = min(maxDelay, baseDelay * 2^attempt)

with random jitter:

wait = random(0, backoff)

For example:

Attempt 1: 0.5s - 1.0s
Attempt 2: 1.0s - 2.0s
Attempt 3: 2.0s - 4.0s

Use an upper bound, and stop retrying when the operation should surface an error to the user.

9. Offline-First Does Not Mean "Always Work Offline"

Offline-first means the product has an explicit strategy for limited connectivity.

For read-heavy applications, a common flow is:

UI
 |
 v
Repository
 |
 +----> Local DB ----> immediate render
 |
 +----> Network ----> refresh local DB

The screen can display cached content immediately, then update when fresh data arrives.

For writes, the architecture is more complex:

User Action
    |
    v
Local Transaction
    |
    +--> pending operation queue
    |
    v
UI updates optimistically
    |
    v
Sync Worker
    |
    +--> success -> mark synced
    |
    +--> conflict -> resolve
    |
    +--> transient error -> retry
    |
    +--> permanent error -> surface action

The conflict strategy must be explicit. Some domains can use last-write-wins. Others need version numbers, server reconciliation, or user intervention.

10. Cache With Semantics

Caching is not simply:

if cachedData != null return cachedData

The application needs to know what the cache means.

A practical model is:

Fresh
Stale-but-usable
Expired
Missing

For example:

data class Cached<T>(
    val value: T,
    val fetchedAt: Instant
) {
    fun isStale(now: Instant, ttl: Duration): Boolean =
        now - fetchedAt > ttl
}

Different data should have different TTLs.

A user profile may tolerate minutes or hours. Stock prices, delivery tracking, and chat messages require a very different strategy.

11. Deep Links Are Part of Navigation Architecture

A deep link should not simply open a screen.

Consider:

myapp://orders/123

What happens when the user is logged out?

A robust navigation pipeline is closer to:

Deep Link
   |
   v
Parse Route
   |
   v
Validate Parameters
   |
   +--> authenticated? -- no --> Login
   |                                |
   |                                v
   |                            restore intent
   |
   +--> yes --> load resource --> render

The original route should survive authentication where appropriate.

You also need to think about invalid IDs, deleted resources, permissions, and links opened from cold start versus warm start.

12. Push Notifications Need Idempotent Navigation

A notification may be delivered more than once or opened after the underlying resource changes.

Do not blindly navigate from the payload.

Instead:

Notification Payload
        |
        v
Validate
        |
        v
Map to Application Intent
        |
        v
Check Auth / Permissions
        |
        v
Fetch Current Data
        |
        v
Navigate

This prevents the client from treating notification payloads as authoritative business data.

13. Design for Partial Failure

A mobile application rarely fails completely. Usually, only part of the experience fails.

Example:

Dashboard
├── User profile      -> OK
├── Recommendations   -> timeout
├── Notifications     -> OK
└── Orders             -> stale cache

The correct UI is not necessarily a full-screen error.

A better approach is to make independent components fail independently:

DashboardState {
    profile: Content
    recommendations: Error
    notifications: Content
    orders: StaleContent
}

This increases resilience and gives users a useful product even when one dependency is unavailable.

14. Security Starts at the Data Boundary

Do not store sensitive data just because storage is convenient.

Classify data first:

Public
Internal
Sensitive
Secrets / Credentials

For credentials and tokens, use platform secure storage rather than ordinary preferences or an unencrypted database.

Also consider:

certificate and TLS validation
secure logging
least-privilege permissions
secure deep-link validation
input validation
server-side authorization
protection against replay
dependency updates

A mobile client is an untrusted environment. Any authorization decision that matters must be enforced by the server.

15. Observability Must Exist Before the First Incident

A production app without telemetry makes debugging guesswork.

At minimum, track:

app_start
screen_view
api_request_failed
api_request_duration
auth_refresh
sync_started
sync_failed
purchase_started
purchase_completed

Avoid logging secrets and personally sensitive values.

For an API request, useful telemetry might include:

{
  "operation": "GET /orders",
  "duration_ms": 483,
  "status": 200,
  "retry_count": 0,
  "network": "wifi",
  "app_version": "3.4.1"
}

A request ID or trace ID shared between mobile and backend services can make distributed debugging dramatically easier.

16. Performance: Measure the Critical Path

Avoid premature optimization, but measure the parts that directly affect user-perceived latency.

For a cold start, the critical path might be:

Process launch
 -> dependency initialization
 -> storage initialization
 -> authentication restore
 -> first screen render

Do not block the first meaningful render on work that does not need to happen first.

For network-bound screens, measure:

DNS
TCP/TLS
request queue time
server time
payload transfer
deserialization
render

This gives you a performance budget that can be acted upon instead of a vague statement such as "the app feels slow."

17. API Design Should Match Client Behavior

A mobile client often works on unreliable networks and constrained devices. APIs should account for that.

Useful properties include:

pagination
stable resource identifiers
explicit error codes
versioned contracts
idempotency for important writes
partial update semantics
cache headers where appropriate
compact payloads

For example, returning 5,000 records because the mobile client "might need them later" creates unnecessary transfer and memory costs.

Cursor-based pagination is often more robust for rapidly changing collections:

GET /orders?limit=20&cursor=eyJpZCI6MTIzfQ==

The client should not have to download the entire collection to display the first screen.

18. Testing Should Target Failure Paths

The strongest mobile test suite is not the one with the most screenshot tests. It is the one that exercises the state transitions that are easy to break.

Test cases should include:

valid response
empty response
slow response
timeout
401 + refresh
401 + refresh failure
429
500
offline
cache hit
stale cache
conflict
process restart
rotation / configuration change
background -> foreground
notification cold start
duplicate mutation

For a repository, tests might assert:

@Test
fun `timeout returns cached value when cache is usable`() = runTest {
    // arrange
    // act
    // assert
}

For synchronization logic, property-based or state-transition testing can uncover combinations that example-based tests miss.

19. Product Design and Engineering Design Are Connected

A technically clean architecture can still produce a poor product if the user flow is wrong.

Before implementing a feature, define:

User goal
Primary action
Required data
Failure states
Permission requirements
Offline behavior
Success state
Recovery action

This is where product and engineering design meet. A serious mobile product needs both interaction design and implementation architecture; the mobile app design process used by AzkiWeb is an example of treating UX flows, API integration, authentication, testing, and technology selection as connected decisions rather than isolated deliverables.

The important lesson is not that a particular agency or framework is always correct. The lesson is that product design and technical architecture should be considered together.

20. A Practical Pre-Release Checklist

Before shipping a production mobile application, verify at least the following:

Architecture

Are domain rules independent from UI frameworks?
Are repositories responsible for data access rather than screens?
Can the networking layer be tested independently?

State

Are loading, empty, error, stale, and success states explicit?
Can partial failures be represented?
Can the screen recover without restarting the app?

Networking

Are timeouts configured?
Are retries limited and policy-driven?
Are important mutations idempotent?
Is token refresh concurrency-safe?

Offline

Is cached data usable?
Are writes queued safely?
What happens after process termination?
How are conflicts resolved?

Security

Are credentials stored using secure platform facilities?
Are secrets excluded from logs?
Are authorization decisions enforced on the server?
Are deep links validated?

Performance

Is cold-start time measured?
Are API and rendering bottlenecks observable?
Are large lists paginated?
Are unnecessary blocking operations removed from the critical path?

Testing

Are failure paths covered?
Are background/foreground transitions tested?
Are duplicate actions tested?
Are authentication edge cases covered?

Conclusion

Production mobile application design is mostly about managing uncertainty.

The happy path is easy to draw:

Tap -> Request -> Response -> Render

The real system looks more like:

Tap
 |
 +--> offline?
 |
 +--> loading?
 |
 +--> duplicate action?
 |
 +--> expired token?
 |
 +--> timeout?
 |
 +--> server error?
 |
 +--> stale cache?
 |
 +--> process restart?
 |
 +--> partial failure?
 |
 +--> conflict?
 |
 v
Recoverable application state

When those cases are designed before implementation, the codebase becomes easier to reason about and the product becomes more resilient.

Good mobile engineering is not simply choosing Flutter, React Native, Swift, Kotlin, or another stack. The important work is defining boundaries, modeling state, making data ownership explicit, designing for unreliable networks, and giving every important failure a deliberate recovery path.

That is what turns a collection of mobile screens into a production system.

HTTP Security Headers Explained: A Practical Guide for Developers

az hala — Thu, 03 Sep 2026 20:54:39 +0000

HTTP Security Headers Explained: A Practical Guide for Developers

A website can use HTTPS, strong passwords, authentication, and secure application code and still have security weaknesses that browsers can help mitigate.

One of the simplest ways to add another layer of protection is through HTTP security headers.

Security headers allow a web server to tell the browser how certain resources should be handled, whether a page can be embedded, which origins can load content, and how much information should be included in referrer requests.

In this guide, we'll look at the most important security headers, explain what they do, and show practical configuration examples for modern websites.

What Are HTTP Security Headers?

HTTP security headers are response headers sent by a web server to a browser.

For example, a server might return:

HTTP/2 200
Content-Type: text/html; charset=UTF-8
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

The browser reads these headers and adjusts its behavior based on the policies provided by the server.

Security headers can help reduce the impact of several common web security problems, including:

Cross-site scripting (XSS)
Clickjacking
MIME-type confusion
Unsafe resource loading
Unnecessary referrer information exposure
Some cross-origin security risks

However, security headers are not a replacement for secure application development.

You still need proper authentication, authorization, input validation, output encoding, secure session management, HTTPS, dependency management, and other security practices.

Think of security headers as an additional defensive layer.

1. Content-Security-Policy (CSP)

Content-Security-Policy, commonly called CSP, is one of the most powerful security headers available to web developers.

CSP allows you to control where browsers can load resources such as:

JavaScript
CSS
Images
Fonts
Frames
Media
Connections

A very simple policy is:

Content-Security-Policy: default-src 'self'

This tells the browser that resources should generally come from the same origin.

A more realistic example could be:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:;

The exact policy depends entirely on the application.

For example, if your website uses third-party analytics, payment services, video embeds, or CDNs, those resources may need to be explicitly allowed.

Why CSP Matters

One important benefit of CSP is reducing the impact of certain XSS attacks.

If an attacker manages to inject a script into a page but the script violates the site's CSP, the browser can refuse to execute it.

That makes CSP an important defense-in-depth mechanism.

Test CSP Before Enforcing It

A restrictive CSP can accidentally break a website.

For an existing application, you can test a policy with:

Content-Security-Policy-Report-Only: default-src 'self'

Report-only mode allows developers to identify policy violations without immediately blocking the resources.

Once the policy has been tested and adjusted, it can be moved to the normal Content-Security-Policy header.

2. Strict-Transport-Security (HSTS)

HTTP Strict Transport Security tells browsers that a website should be accessed using HTTPS.

A basic configuration looks like this:

Strict-Transport-Security: max-age=31536000

The value is expressed in seconds.

For example, 31536000 represents one year.

A configuration may also include subdomains:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Be Careful With HSTS

HSTS should not be enabled blindly.

Before using includeSubDomains, make sure the relevant subdomains are correctly configured for HTTPS.

Otherwise, users could have problems accessing services that still depend on HTTP.

HSTS is particularly useful for helping prevent protocol downgrade attacks and ensuring that browsers consistently use HTTPS after receiving the policy.

3. X-Content-Type-Options

This is one of the simplest security headers to configure.

X-Content-Type-Options: nosniff

The nosniff value tells browsers not to try to guess the MIME type of certain resources.

Web servers should correctly specify the content type of files such as JavaScript, CSS, images, and other resources.

For many websites, adding this header is a straightforward security improvement.

4. Referrer-Policy

When a browser navigates from one page to another, it can send information about the previous page through the Referer request header.

Depending on the URL structure of your website, that information may reveal more than you want to share.

A commonly useful policy is:

Referrer-Policy: strict-origin-when-cross-origin

This generally provides more limited information when navigating between different origins while retaining useful referrer information for same-origin requests.

Other policies include:

Referrer-Policy: no-referrer

and:

Referrer-Policy: same-origin

The right choice depends on the privacy and analytics requirements of your application.

5. Permissions-Policy

Modern browsers expose powerful features such as:

Camera
Microphone
Geolocation
Sensors
Fullscreen
USB
Other browser capabilities

Permissions-Policy allows developers to control which origins can use specific features.

For example:

Permissions-Policy: camera=(), microphone=(), geolocation=()

This configuration disables camera, microphone, and geolocation access for the document.

If your application does not need a browser capability, restricting it can reduce unnecessary exposure.

If the application actually requires a feature, the policy should be configured accordingly.

6. X-Frame-Options and Clickjacking

Clickjacking occurs when an attacker attempts to trick users into interacting with a website through an embedded frame.

A traditional defense is:

X-Frame-Options: DENY

This prevents the page from being framed.

Another option is:

X-Frame-Options: SAMEORIGIN

This allows framing by pages from the same origin.

Modern applications can also use CSP's frame-ancestors directive:

Content-Security-Policy: frame-ancestors 'self'

The exact configuration depends on whether your website needs to be embedded by other pages.

7. Cross-Origin Security Headers

Modern web applications may also use headers that control relationships between documents and resources from different origins.

Three headers you may encounter are:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

These headers have different purposes.

Cross-Origin-Opener-Policy

COOP controls how a document interacts with browsing contexts from other origins.

Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Resource-Policy

CORP allows a resource to specify which origins can load it.

Cross-Origin-Resource-Policy: same-origin

Cross-Origin-Embedder-Policy

COEP controls whether cross-origin resources can be embedded under specific conditions.

Cross-Origin-Embedder-Policy: require-corp

These policies can affect third-party resources, so they should be introduced carefully and tested against the actual application.

A Practical Starting Configuration

A basic security configuration might look like this:

Content-Security-Policy: default-src 'self'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: SAMEORIGIN

But this should not be treated as a universal copy-and-paste configuration.

Every application is different.

For example, a website that uses Google Fonts, YouTube, analytics platforms, advertising networks, payment gateways, or external JavaScript libraries may require a more specific CSP.

Always test your configuration before deploying it to production.

Configuring Security Headers With Apache

Apache HTTP Server can configure response headers using mod_headers.

For example:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

HSTS can be added after HTTPS has been correctly configured:

Header always set Strict-Transport-Security "max-age=31536000"

Make sure the relevant Apache modules and configuration permissions are available on your hosting environment.

Configuring Security Headers With Nginx

Nginx uses the add_header directive.

For example:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

HSTS can be configured as:

add_header Strict-Transport-Security "max-age=31536000" always;

Again, verify your HTTPS configuration before enabling HSTS.

Configuring Headers in Node.js

If you're building a Node.js application, you can set response headers in application code.

A simple example is:

app.use((req, res, next) => {
  res.setHeader("X-Content-Type-Options", "nosniff");

  res.setHeader(
    "Referrer-Policy",
    "strict-origin-when-cross-origin"
  );

  res.setHeader("X-Frame-Options", "SAMEORIGIN");

  next();
});

For larger applications, security middleware can make header management easier.

However, developers should still understand what the individual headers actually do.

Using middleware without understanding the policies can make debugging much harder.

How to Check Security Headers

You don't necessarily need a specialized tool to inspect HTTP response headers.

One of the simplest methods is using curl:

curl -I https://example.com

You may see something similar to:

HTTP/2 200
content-type: text/html
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000

You can also inspect headers directly from your browser.

Open Developer Tools, go to the Network tab, reload the page, select the main document request, and inspect the Response Headers section.

This is especially useful when troubleshooting a missing or incorrectly configured header.

Automating Security Header Audits

If you regularly work with multiple websites, manually checking every response becomes repetitive.

A security header checker can automate the process.

A basic scanner can:

Accept a URL.
Make an HTTP or HTTPS request.
Follow redirects.
Read the final response headers.
Check important security policies.
Identify missing headers.
Produce a report or score.

A simplified Node.js example might look like:

const response = await fetch(url);

const headers = response.headers;

const result = {
  contentSecurityPolicy:
    headers.get("content-security-policy"),

  strictTransportSecurity:
    headers.get("strict-transport-security"),

  contentTypeOptions:
    headers.get("x-content-type-options"),

  referrerPolicy:
    headers.get("referrer-policy"),

  permissionsPolicy:
    headers.get("permissions-policy")
};

console.log(result);

A production-grade scanner requires much more than this small example.

Important considerations include:

Redirect limits
Request timeouts
TLS certificate validation
DNS resolution
IPv4 and IPv6 handling
Private network protection
SSRF prevention
Rate limiting
Abuse prevention
Maximum response sizes
Error handling

If a tool accepts arbitrary URLs, SSRF protection is especially important.

A server should not blindly make requests to internal services or private network addresses.

Security Headers and Technical SEO

Security headers are primarily security mechanisms rather than direct search-engine ranking factors.

However, security and technical SEO can overlap in several areas.

For example, incorrect HTTPS configuration can cause redirect problems.

An overly restrictive CSP can prevent important resources from loading.

Broken redirects can interfere with crawling and canonicalization.

Mixed-content problems can affect page functionality.

Server reliability can also influence how users and automated crawlers experience a website.

This means security configuration should be considered alongside other technical website practices such as:

Crawlability
HTTPS
Canonical URLs
Structured data
Mobile rendering
Page performance
Internal linking
Server responses

For developers and website owners working on broader technical SEO, understanding how the server and browser interact is just as important as optimizing page content.

Common Security Header Mistakes

Mistake 1: Copying a CSP Without Testing

CSP is powerful, but an overly restrictive policy can break legitimate resources.

Always test the policy against your actual application.

Mistake 2: Enabling HSTS Too Early

HSTS can create accessibility problems if parts of your infrastructure are not ready for HTTPS.

Verify your domain and relevant subdomains before deploying an aggressive HSTS policy.

Mistake 3: Adding Every Header You Find

More headers do not automatically mean better security.

Security policies should address the actual requirements of your application.

A poorly configured policy can create compatibility problems without providing meaningful protection.

Mistake 4: Forgetting Third-Party Resources

Modern websites often depend on external services.

Your CSP and other policies should account for legitimate third-party resources without unnecessarily allowing everything.

Mistake 5: Testing Only the Homepage

Different routes can be handled differently.

For example:

/
 /login
 /dashboard
 /api/
 /static/

may be served through different application layers, proxies, or services.

Important routes should therefore be included in your security testing.

Security Header Audit Checklist

Use this checklist when reviewing a website:

[ ] HTTPS is correctly configured
[ ] HSTS is appropriate for the domain
[ ] CSP is present and tested
[ ] X-Content-Type-Options is configured
[ ] Referrer-Policy is configured
[ ] Permissions-Policy has been reviewed
[ ] Clickjacking protection is configured
[ ] Cross-origin policies are reviewed where necessary
[ ] Redirects behave correctly
[ ] Third-party resources are accounted for
[ ] Important routes return the expected headers
[ ] Security policies do not break legitimate functionality

Final Thoughts

HTTP security headers provide an additional layer of browser-enforced protection for modern websites.

The most important lesson is not to copy a list of headers and assume the website is secure.

Instead, use a process:

Understand → Configure → Test → Monitor → Improve

Start with the policies that make sense for your application.

If you manage multiple websites, automating security-header checks can also save time and make configuration problems easier to identify.

Building a small security-header scanner is an excellent practical project for developers because it combines HTTP, networking, backend development, browser security, and real-world web infrastructure.

Security headers are only one part of a secure website, but they are a practical and useful place to start.

DEV Community: az hala

Designing Production-Grade Mobile Apps: Architecture, State, Offline-First, and Failure Handling

Designing Production-Grade Mobile Apps

1. Start With a System Model, Not a Screen List

2. Use Explicit Architectural Boundaries

3. Treat UI State as a State Machine

4. Separate Remote State, Local State, and UI State

5. Design Networking Around Failure, Not Just HTTP 200

6. Token Refresh Needs Concurrency Control

7. Retry Is a Policy, Not a Reflex

8. Use Exponential Backoff With Jitter

9. Offline-First Does Not Mean "Always Work Offline"

10. Cache With Semantics

11. Deep Links Are Part of Navigation Architecture

12. Push Notifications Need Idempotent Navigation

13. Design for Partial Failure

14. Security Starts at the Data Boundary

15. Observability Must Exist Before the First Incident

16. Performance: Measure the Critical Path

17. API Design Should Match Client Behavior

18. Testing Should Target Failure Paths

19. Product Design and Engineering Design Are Connected

20. A Practical Pre-Release Checklist

Architecture

State

Networking

Offline

Security

Performance

Testing

Conclusion

HTTP Security Headers Explained: A Practical Guide for Developers

HTTP Security Headers Explained: A Practical Guide for Developers

What Are HTTP Security Headers?

1. Content-Security-Policy (CSP)

Why CSP Matters

Test CSP Before Enforcing It

2. Strict-Transport-Security (HSTS)

Be Careful With HSTS

3. X-Content-Type-Options

4. Referrer-Policy

5. Permissions-Policy

6. X-Frame-Options and Clickjacking

7. Cross-Origin Security Headers

Cross-Origin-Opener-Policy

Cross-Origin-Resource-Policy

Cross-Origin-Embedder-Policy

A Practical Starting Configuration

Configuring Security Headers With Apache

Configuring Security Headers With Nginx

Configuring Headers in Node.js

How to Check Security Headers

Automating Security Header Audits

Security Headers and Technical SEO

Common Security Header Mistakes

Mistake 1: Copying a CSP Without Testing

Mistake 2: Enabling HSTS Too Early

Mistake 3: Adding Every Header You Find

Mistake 4: Forgetting Third-Party Resources

Mistake 5: Testing Only the Homepage

Security Header Audit Checklist

Final Thoughts

Further Reading