Applying HTTPS and Secure Network Communication in Android

Course: Android App Development

Topic: Applying HTTPS and Secure Network Communication

Course Link: Android App Development Course

Demo Link: Register for a Course Demo

Website: JustAcademy Official Website

1. Introduction to HTTPS and Secure Network Communication

Android applications frequently communicate with remote servers to authenticate users, retrieve information, upload files, process payments, synchronize data, and send notifications. These interactions may contain sensitive information that must be protected against unauthorized access and modification.

HTTPS is the secure version of HTTP. It uses Transport Layer Security (TLS) to encrypt communication between a client and a server, authenticate the server, and protect data against undetected modification while it travels across the network.

Without appropriate network security, attackers on an untrusted Wi-Fi network or another network position may be able to inspect or manipulate unencrypted traffic. Secure network communication is therefore a fundamental requirement for modern Android applications.

Android provides networking APIs and security configuration options that help developers establish trusted connections. However, applications must use these tools correctly, validate server certificates, protect authentication tokens, and enforce authorization on the backend.

2. Learning Objectives

• Understand HTTP, HTTPS, SSL, and TLS.
• Explain encryption, server authentication, and data integrity.
• Configure Android applications to use HTTPS endpoints.
• Make secure network requests using Android networking APIs.
• Configure Android Network Security Configuration.
• Understand certificates, certificate authorities, and trust validation.
• Handle network errors, timeouts, and HTTP response codes.
• Protect API credentials, authentication tokens, and sensitive information.
• Understand certificate pinning and its operational risks.
• Test secure communication and troubleshoot common network problems.

3. Understanding HTTP and HTTPS

3.1 What Is HTTP?

HTTP stands for Hypertext Transfer Protocol. It defines how clients and servers exchange requests and responses. An Android application may use HTTP to request JSON data, upload a document, or retrieve information from a web service.

Ordinary HTTP does not encrypt the transmitted information. An attacker able to observe or manipulate the traffic may be able to read or alter its contents.

3.2 What Is HTTPS?

HTTPS is HTTP communicated over TLS. TLS establishes a protected connection between the client and server before application data is exchanged.

For example, an Android application that sends a login request to https://api.example.com/login can protect the credentials in transit when the connection is configured correctly and the server certificate is valid.

4. Understanding SSL and TLS

SSL stands for Secure Sockets Layer, an older protocol family that is now obsolete. TLS stands for Transport Layer Security and is its modern successor. Developers should use current, platform-supported TLS implementations instead of attempting to implement cryptographic protocols themselves.

When an Android application connects to an HTTPS server, the TLS handshake establishes the security parameters for the connection and authenticates the server using its certificate chain and the client's trust configuration.

4.1 Main TLS Security Properties

• Confidentiality: Encryption prevents network observers from reading transmitted application data.
• Integrity: Cryptographic protections help detect unauthorized modification of data in transit.
• Server authentication: Certificate validation helps the client confirm that it is communicating with the intended server.
• Session security: TLS establishes keys used to protect data exchanged during the connection.

HTTPS does not automatically protect data after it reaches the server, prevent insecure application logic, or guarantee that a user is authorized to access a resource. Those protections require additional controls.

5. How HTTPS Communication Works

A simplified HTTPS connection follows these steps:

1. The Android application connects to the server using an HTTPS URL.
2. The client and server negotiate TLS parameters.
3. The server presents its TLS certificate and associated certificate chain.
4. The client validates the certificate chain, validity dates, hostname, and trust requirements.
5. The TLS handshake establishes cryptographic session keys.
6. The client and server exchange HTTP requests and responses through the protected connection.
7. The connection may be reused for additional requests, depending on the networking library and connection settings.

If certificate validation fails, the client should normally reject the connection. Developers must not bypass validation simply to make a failing request succeed.

6. Understanding Digital Certificates

A digital certificate binds a public key to an identity, such as a domain name. HTTPS servers use certificates as part of TLS server authentication.

Certificates are commonly issued by certificate authorities (CAs). Android trusts certificates according to its system trust configuration and any application-specific Network Security Configuration.

6.1 Important Certificate Concepts

7. Adding Internet Permission

Android applications that access remote servers generally need the Internet permission in the manifest.

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-permission android:name="android.permission.INTERNET" />

    <application
        android:label="SecureNetworkApp">
        ...
    </application>
</manifest>

The Internet permission is a normal permission and does not require a runtime permission prompt. It allows the app to open network connections; it does not itself make those connections secure.

8. Making an HTTPS Request with HttpsURLConnection

HttpsURLConnection is a Java networking API available on Android for HTTPS communication. Network operations must not run on the main UI thread because slow requests can make the application unresponsive.

The following example shows a simple request inside a background coroutine.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.net.URL
import javax.net.ssl.HttpsURLConnection

suspend fun fetchServerResponse(): String =
    withContext(Dispatchers.IO) {
        val url = URL("https://api.example.com/status")
        val connection =
            url.openConnection() as HttpsURLConnection

        try {
            connection.requestMethod = "GET"
            connection.connectTimeout = 10000
            connection.readTimeout = 10000

            val responseCode = connection.responseCode

            if (responseCode in 200..299) {
                connection.inputStream.bufferedReader().use {
                    it.readText()
                }
            } else {
                throw IllegalStateException(
                    "Server returned HTTP $responseCode"
                )
            }
        } finally {
            connection.disconnect()
        }
    }

Replace the example domain with your actual HTTPS API endpoint. This example illustrates basic connection management; production applications should use a suitable networking or repository layer, parse responses safely, and handle expected network exceptions.

9. Using a Modern Networking Library

Libraries such as OkHttp and Retrofit are commonly used in Android applications to simplify HTTP requests, serialization, connection management, and error handling.

For example, Retrofit can define a typed API interface while OkHttp manages the underlying HTTP connections. Use maintained versions and preserve their standard TLS certificate and hostname validation behavior.

9.1 Example Retrofit API Interface

import retrofit2.Response
import retrofit2.http.GET

data class StatusResponse(
    val status: String,
    val message: String
)

interface StatusApi {
    @GET("status")
    suspend fun getStatus(): Response<StatusResponse>
}

The Retrofit base URL should use HTTPS:

val baseUrl = "https://api.example.com/"

Configure Retrofit with an appropriate converter and a maintained HTTP client. Do not install a trust manager that accepts every certificate or a hostname verifier that accepts every hostname.

10. Configuring Network Security in Android

Android Network Security Configuration allows developers to declare network security policies in XML rather than writing custom networking code. It can control cleartext traffic, define custom trust anchors, support debug-only certificates, and configure other domain-specific security behavior.

For production applications, allowing cleartext traffic should generally be avoided. Android versions and target SDK levels have different defaults, so explicitly reviewing the final configuration is important.

10.1 Create the Configuration File

Create the following file in the Android project:

app/src/main/res/xml/network_security_config.xml

Example configuration that disables cleartext traffic:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

This configuration requests that supported networking components reject unencrypted HTTP traffic. It does not replace the need for correct TLS certificate validation or secure server-side design.

10.2 Connect the Configuration to the Manifest

<application
    android:networkSecurityConfig="@xml/network_security_config"
    android:label="SecureNetworkApp">
    ...
</application>

Confirm that the XML file is located in the correct resource directory and that the manifest references the correct resource name.

11. Understanding Cleartext Traffic

Cleartext traffic is network communication that is not encrypted at the transport layer. Ordinary HTTP is a common example.

Cleartext traffic can expose data to network observers and may allow attackers to manipulate responses. It can also create risks when an attacker changes a server-provided URL or redirects the application to an insecure endpoint.

For applications targeting Android 9 (API level 28) and later, cleartext traffic is disabled by default for supported platform networking components unless configuration permits it. Older target SDK levels have different defaults. Third-party libraries and custom networking code should also be reviewed rather than assuming every connection automatically follows the same policy.

11.1 Avoid Global HTTP Exceptions

Do not enable cleartext traffic globally just to fix one development connection problem. If a narrowly scoped exception is genuinely required for a controlled development environment, keep it isolated from release builds and remove it before production.

12. Using Debug-Only Certificates

During development, an application may need to trust a certificate issued by a development certificate authority. Android Network Security Configuration supports debug-only trust overrides so additional certificates can be trusted when the app is marked debuggable, without extending that trust to the release configuration.

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas" />
        </trust-anchors>
    </debug-overrides>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

The example assumes that a valid debug certificate resource named debug_cas has been created. Debug-only trust should be limited to controlled testing. Never solve a development certificate issue by accepting every certificate in production.

13. Certificate Validation and Common Errors

Certificate validation helps the client verify the server's identity. If the certificate chain is untrusted, expired, incorrectly configured, or issued for a different hostname, the HTTPS connection may fail.

Do not bypass certificate validation to suppress these errors. Correct the underlying server, DNS, certificate, or trust configuration instead.

14. Avoiding Insecure Trust Managers

A common but dangerous mistake is creating a custom trust manager that accepts every server certificate. Another is creating a hostname verifier that always returns true.

These shortcuts can make invalid certificates appear acceptable and undermine HTTPS server authentication. They may expose users to interception attacks, even when the URL begins with HTTPS.

14.1 Unsafe Patterns to Avoid

• Trust managers that accept every certificate.
• Hostname verifiers that accept every hostname.
• Disabling TLS verification to work around a self-signed certificate.
• Using outdated or insecure TLS implementations.
• Allowing unencrypted HTTP for sensitive production APIs.

Use the platform's standard trust configuration or a carefully designed, maintained alternative that meets a documented security requirement.

15. Understanding Certificate Pinning

Certificate pinning is a technique that restricts the certificates or public keys an application accepts for a particular server. It can reduce reliance on the broader certificate authority system, but it also creates operational risks if certificates or keys change unexpectedly.

Android Network Security Configuration supports pin sets for applicable domains. If pinning is used, developers must plan for certificate rotation, include suitable backup pins, and ensure that a recovery path exists before deploying the policy.

15.1 Important Considerations

• Do not add pinning automatically without evaluating the threat model.
• Maintain backup pins when the design requires them.
• Plan and test certificate and key rotation.
• Monitor expiration and deployment changes.
• Avoid brittle configurations that can permanently disconnect legitimate users.
• Document how emergency recovery will be handled.

For many applications, correct HTTPS usage, standard certificate validation, secure server configuration, and effective backend authorization provide a strong baseline without custom pinning.

16. Secure Authentication over HTTPS

Authentication requests often contain passwords, authorization codes, or tokens. HTTPS protects these values while they travel between the application and server, but the app must also handle them securely before and after transmission.

• Send credentials only to trusted HTTPS endpoints.
• Avoid placing passwords or tokens in URL query parameters.
• Never log credentials, cookies, or bearer tokens.
• Store session material only when necessary and protect it appropriately.
• Use short-lived tokens and refresh mechanisms where appropriate.
• Enforce session expiry, revocation, and authorization on the backend.
• Validate server responses and handle authentication failures safely.

16.1 Example of an Authorization Header

val request = okhttp3.Request.Builder()
    .url("https://api.example.com/profile")
    .header("Authorization", "Bearer $accessToken")
    .get()
    .build()

This snippet illustrates how a bearer token may be attached to a request. The surrounding HTTP client must be configured securely, and the token must be obtained, stored, refreshed, and revoked according to the application's authentication design. Never hardcode a real access token in source code.

17. Secure API Response Handling

Even when an API uses HTTPS, the application must validate responses and handle unexpected content safely. A secure transport connection does not guarantee that the server's business logic is correct or that every response is valid for the application.

• Check the HTTP status code before processing a response as successful.
• Validate required fields and data types.
• Handle empty, malformed, or unexpectedly large responses.
• Apply reasonable timeouts and cancellation.
• Use pagination or streaming for large data sets where appropriate.
• Do not expose internal error details directly to users.
• Keep authorization decisions on the backend for protected resources.

18. Handling HTTP Status Codes

HTTP status codes help applications understand the result of a request.

19. Timeouts, Retries, and Network Failures

Mobile network connections may be interrupted by changes in connectivity, device sleep, server overload, or other conditions. Applications should handle these failures without freezing the UI or repeating sensitive operations unsafely.

• Configure reasonable connection and read timeouts.
• Run blocking network work off the main thread.
• Cancel requests when their owning operation no longer needs them.
• Retry only failures that are likely to be temporary.
• Use bounded backoff for suitable retry scenarios.
• Respect server rate limits and retry guidance.
• Make non-idempotent operations safe against duplicate submissions when possible.

For example, retrying a request to retrieve a public status may be safe, while retrying a payment request without an idempotency mechanism could create duplicate transactions. The retry policy must match the operation's business behavior.

20. Secure File Uploads and Downloads

Android applications often upload photos, documents, or backups and download reports or media. These transfers should use trusted HTTPS endpoints and carefully validate both the request and the returned content.

20.1 Upload Security

• Use HTTPS for uploads.
• Validate file size and allowed content types.
• Do not trust the filename or MIME type supplied by the client alone.
• Require appropriate authorization for upload operations.
• Use server-side malware scanning or file validation where relevant.
• Avoid logging private file contents or signed upload credentials.

20.2 Download Security

• Download from trusted endpoints.
• Validate response status and content size.
• Choose a suitable destination and file-sharing policy.
• Avoid executing downloaded content without verification.
• Use temporary storage and cleanup where appropriate.
• Protect downloaded sensitive documents from unintended exposure.

21. Secure WebSocket Communication

Some Android applications require real-time communication, such as messaging, collaboration, or live status updates. WebSocket connections should use wss:// for TLS-protected communication rather than unencrypted ws:// when communicating over untrusted networks.

• Validate the server certificate and hostname.
• Authenticate the connection using an appropriate secure mechanism.
• Authorize each sensitive operation on the server.
• Validate messages received from the server.
• Handle disconnects and reconnection without creating excessive traffic.
• Avoid placing long-lived secrets in connection URLs.

22. Secure Network Logging

Network logging can help developers troubleshoot failed requests, slow responses, and server errors. However, logging complete request and response bodies may expose personal information or authentication credentials.

22.1 Recommended Logging Practices

• Record request timing, status codes, and non-sensitive diagnostic identifiers.
• Redact Authorization headers, cookies, and tokens.
• Avoid recording passwords and private response bodies.
• Limit detailed logs to controlled development environments.
• Apply access control and retention policies to production logs.
• Review crash reports and analytics integrations for accidental data collection.

23. Testing HTTPS and Secure Network Communication

Network security testing verifies that the application uses secure endpoints, validates certificates correctly, handles failures safely, and does not accidentally transmit sensitive information through unencrypted channels.

23.1 Testing Checklist

• Confirm that all production API URLs use HTTPS.
• Verify that cleartext traffic is disabled unless a narrowly scoped exception is required.
• Test the app with a valid server certificate.
• Confirm that invalid, expired, and hostname-mismatched certificates are rejected.
• Check that no trust-all manager or permissive hostname verifier exists.
• Verify that authentication tokens are not included in logs or query strings.
• Test network loss, timeouts, and server error responses.
• Check that retry logic does not duplicate sensitive operations.
• Review third-party networking libraries and their configuration.
• Inspect the release manifest and Network Security Configuration.

24. Common Problems and Troubleshooting

25. Practical Project: Building a Secure API Status Checker

In this project, create a small Android feature that calls a secure API endpoint and displays the result. The project demonstrates HTTPS, network permission, background execution, response validation, and error handling.

Step 1: Add Internet Permission

<uses-permission android:name="android.permission.INTERNET" />

Step 2: Configure Network Security

Create res/xml/network_security_config.xml:

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Reference it from the application element in the manifest:

android:networkSecurityConfig="@xml/network_security_config"

Step 3: Create the Network Function

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.net.URL
import javax.net.ssl.HttpsURLConnection

suspend fun checkApiStatus(): String =
    withContext(Dispatchers.IO) {
        val connection =
            URL("https://api.example.com/status")
                .openConnection() as HttpsURLConnection

        try {
            connection.connectTimeout = 10000
            connection.readTimeout = 10000
            connection.requestMethod = "GET"

            val code = connection.responseCode

            if (code in 200..299) {
                connection.inputStream.bufferedReader().use {
                    it.readText()
                }
            } else {
                throw IllegalStateException(
                    "Status request failed: HTTP $code"
                )
            }
        } finally {
            connection.disconnect()
        }
    }

Step 4: Display the Result

Call the function from a lifecycle-aware coroutine, such as a ViewModel scope, and expose a loading state, success result, or safe error message to the UI. Avoid performing the request directly on the main thread.

Step 5: Test Failure Scenarios

• Test with a valid HTTPS endpoint.
• Test while the device has no network connection.
• Test an endpoint that returns an HTTP error status.
• Verify that invalid certificates are rejected.
• Confirm that the UI remains responsive while the request runs.
• Check that no sensitive information appears in logs.

Replace api.example.com with an API server you control or are authorized to test. This example is a learning exercise rather than a complete production networking layer.

26. Best Practices for Production Applications

• Use HTTPS for all production API and file-transfer endpoints.
• Prefer maintained platform APIs and established networking libraries.
• Preserve default TLS certificate and hostname validation.
• Disable cleartext traffic through suitable network security configuration.
• Keep development-only trust settings out of production builds.
• Protect authentication tokens and never hardcode privileged server secrets.
• Enforce authorization and data ownership on the backend.
• Configure reasonable timeouts and cancellation behavior.
• Retry only appropriate failures and prevent duplicate transactions.
• Validate response data before using it.
• Redact sensitive information from logs and telemetry.
• Review certificate renewal and pinning requirements before release.
• Test the actual release build and its network configuration.

27. Practice Exercises

1. Create an Android app that sends a GET request to a trusted HTTPS endpoint.
2. Add the Internet permission and create a Network Security Configuration file.
3. Disable cleartext traffic and verify that an HTTP endpoint is rejected by the supported networking stack.
4. Display the result of a successful request in a TextView or Compose screen.
5. Handle HTTP 401, 403, 404, and 500 responses appropriately.
6. Simulate a timeout and display a user-friendly error message.
7. Review a sample project for trust-all certificate managers and permissive hostname verifiers.
8. Write a checklist for secure token handling and network logging.
9. Investigate a certificate validation error without disabling certificate checks.
10. Test the release build to confirm that development-only trust settings are not enabled.

28. Interview Questions and Answers

Q1. What is HTTPS?

Answer: HTTPS is HTTP over TLS. It protects data in transit through encryption and integrity protections while authenticating the server through certificate validation.

Q2. What is the difference between HTTP and HTTPS?

Answer: Ordinary HTTP does not encrypt traffic, while HTTPS uses TLS to protect communication and authenticate the server when configured correctly.

Q3. What is TLS?

Answer: TLS is a cryptographic protocol that provides confidentiality, integrity, and authentication for network communication.

Q4. Why is certificate validation important?

Answer: It helps the client verify that the server presents a certificate trusted for the intended hostname, reducing the risk of connecting to an impostor.

Q5. What is Android Network Security Configuration?

Answer: It is an XML-based feature for configuring network security policies, including cleartext traffic rules, trust anchors, and certain domain-specific settings.

Q6. Why should developers avoid trust-all certificate managers?

Answer: They accept invalid certificates and undermine server authentication, potentially allowing attackers to intercept or manipulate network traffic.

Q7. What is certificate pinning?

Answer: It restricts which certificates or public keys an app accepts for a server. It requires careful planning for key rotation and recovery to avoid breaking legitimate connections.

Q8. Should network requests run on the main thread?

Answer: No. Blocking network operations should run on an appropriate background dispatcher or executor to keep the user interface responsive.

Q9. Does HTTPS guarantee that an API is secure?

Answer: No. HTTPS protects data in transit, but authentication, authorization, secure data storage, server-side validation, and business logic must also be implemented correctly.

Q10. How should an Android app handle an expired certificate?

Answer: The server operator should renew and correctly deploy the certificate. The app should not bypass validation to hide the error.

Q11. What is cleartext traffic?

Answer: Cleartext traffic is data transmitted without transport encryption, such as ordinary HTTP communication.

Q12. Why should tokens not be placed in URLs?

Answer: URLs may be recorded in server logs, analytics, browser history, and diagnostic systems. Tokens should be transmitted through suitable protected mechanisms, such as an Authorization header over HTTPS.

29. Quick Revision Checklist

• HTTPS uses TLS to protect network communication.
• Server certificates and hostname validation are essential.
• Use HTTPS endpoints for production traffic.
• Declare the Internet permission when required.
• Use Network Security Configuration to establish secure network policies.
• Disable cleartext traffic unless a justified exception is required.
• Never disable certificate validation to fix connection problems.
• Keep tokens and credentials out of logs and URLs.
• Run network operations off the main thread.
• Handle timeouts, response codes, and retries carefully.
• Test debug and release configurations separately.
• Remember that HTTPS does not replace backend authorization.

30. Conclusion

Applying HTTPS and secure network communication is essential for protecting Android applications and their users. HTTPS uses TLS to encrypt data in transit, verify server identity, and protect transmitted information against undetected modification. Android developers can strengthen these protections through correct certificate validation, Network Security Configuration, secure token handling, safe response processing, and careful error management.

Secure networking requires more than changing an HTTP URL to HTTPS. Developers must preserve certificate checks, configure production endpoints correctly, protect authentication data, enforce backend authorization, and test realistic failure scenarios. Following these practices helps build Android applications that communicate reliably and securely.

Continue learning with the JustAcademy Android App Development Course, register for a course demo, or visit the JustAcademy official website.

31. Official Learning Resources

• Android Security Best Practices
• Android Network Security Configuration
• Android Cleartext Communication Risks