Nsexceptionallowsinsecurehttploads Not Working for Ip Addresses

NSExceptionAllowsInsecureHTTPLoads not working for IP addresses

You need to add NSAppTransportSecurity dictionary to your info.plist. Then add
NSAllowsArbitraryLoads key to that dictionary and set the boolean value to YES.

Update

From 2017 January, if you are using the above mentioned method for opting-out from ATS you need to provide a justification to Apple while submitting your app to AppStore.

App Transport Security REQUIRED January 2017

NSAllowsArbitraryLoads not working for ip address

I was able to access that URL, http://152.111.198.244, using ‘Allow Arbitrary Loads’ in my Info.plist under Xcode 7.1 and Simulator 9.1:

• App Transport Security Settings: Dictionary
  
  
  • Allow Arbitrary Loads: Boolean = YES

Screenshot:

I used the following code:

let url = NSURL(string: "http://152.111.198.244")!
let task = NSURLSession.sharedSession().dataTaskWithURL(url) {(data, response, error) -> Void in
    print("response \(response!)")
}
task.resume()

Here is the response that I received:

response <NSHTTPURLResponse: 0x7fe1a2421f80> { URL: http://152.111.198.244/auth/login } { status code: 200, headers {
    "Cache-Control" = "no-cache";
    Connection = "Keep-Alive";
    "Content-Encoding" = gzip;
    "Content-Length" = 1138;
    "Content-Type" = "text/html; charset=UTF-8";
    Date = "Fri, 23 Oct 2015 09:33:59 GMT";
    "Keep-Alive" = "timeout=5, max=98";
    Server = "Apache/2.4.7 (Ubuntu)";
    "Set-Cookie" = "XSRF-TOKEN=eyJpdiI6IldBOWYxcDk3SEtMekJ3YTNSUm9mYUE9PSIsInZhbHVlIjoiTFBcL3RGWW10cjlONFFkeXY1ZDA4SWRkSURIYlFsOGE3QkFEV3hRNTVwRFJuWSt5SXN3OU55Sng4elduMHd1T1duV0VFQ1o4dDVjeDJTZGRFeXJxMjN3PT0iLCJtYWMiOiJiZjNmOTg0NTZmY2RkMGQzNmE2YWEyNjJiNzA1MDlmZjIwM2M3NWYyNjYwZjM5N2Q3ZTgxNjRjNzAzMGYzYmMzIn0%3D; expires=Fri, 23-Oct-2015 11:33:59 GMT; Max-Age=7200; path=/, laravel_session=eyJpdiI6InR5OSs3cmpObVRBbFhORnVJQjRvWFE9PSIsInZhbHVlIjoiSTJ2bk41RVVLZUR1a0xKbFwvalZXQWpsNEtWeHppUVpYVUlRM1ZjQXc5aDJxT1wvXC9uYkViaTQ0SCtGNTMrdmtiQXFOd0VJTFwvM0ZCbmFHZk5MWlwvZ3BBUT09IiwibWFjIjoiYjRmNzcxY2Q5NDFlZjYzZTI1YzU2YzI0YTkxM2M0NDg0MGY2YThiODIxOGZjOTgxYjNmM2FlZTkzZGMyZTdjOCJ9; expires=Fri, 23-Oct-2015 11:33:59 GMT; Max-Age=7200; path=/; httponly";
    Vary = "Accept-Encoding";
    "X-Powered-By" = "PHP/5.5.9-1ubuntu4.11";
} }

I was also able to connect using the named domain 3d.media24.com but not the numeric address of 152.111.198.244 using exception domains.

Screenshot:

My results agree with the definition for exception domains in the Apple Technote on App Transport Security:

A dictionary of exceptions for the named domain. The name of the key is the name of the domain–for example, www.apple.com.

NSAllowsArbitraryLoads not working

I feel so stupid. I added the keys for disabling the ATS on the wrong Info.plist. Instead of adding it in the Supporting Files/Info.plist file, I added it on MyAppTests/Supporting Files/Info.plist file. Not really a bug in Xcode, but a bug in my brain. Thank you all for your answers!

Transport security has blocked a cleartext HTTP

If you are using Xcode 8.0+ and Swift 2.2+ or even Objective C:

If you want to allow HTTP connections to any site, you can use this keys:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

If you know which domains you will connect to add:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSIncludesSubdomains</key>
            <true/>
        </dict>
    </dict>
</dict>

Accessing local ip address using xcode

Actually, the real problem is that ATS exception domains do not work with IP addresses. It only works with domain names.

Options:

Option 1 - disable ATS

Turning off ATS altogether is a not a great idea if you are submitting your app to the app store - doing so will cause you to justify that decision if you wish to submit to the app store when Apple starts enforcing that rule. Normally I do not recommend this as an option on SO. However, considering that you are puttinga hard coded IP address in there, I suspect this is a single use app created for a particular use case, and you will not need to submit to Apple for review (you will probably be installing directly on a device using a development provisioning profile). If that's the case, I would just disable ATS entirely using the NSAllowsArbitraryLoads key in your Info.plist.

This will disable all ATS protections, but if your app is only communicating with the local network entity via HTTPS, App Transport Security wouldn't have been protecting anything anyway.

Option 2 - use NSAllowsLocalNetworking

If you put both NSAllowsArbitraryLoads and NSAllowsLocalNetworking in your Info.plist, in iOS 9, you will disable ATS entirely, but in iOS 10 (the first version that supported the NSAllowsLocalNetworking setting), iOS will ignore the NSAllowsArbitraryLoads and only disable ATS on local network calls. This would be more secure, but if you're ONLY making local networking calls, I would just disable ATS (Option 1).

Option 3 - xip.io

If you want to leave ATS on, others have had success using xip.io service to "convert" the local IP address to a domain name. So you would add xip.io to the Exception domains, set the subvalue for NSIncludesSubdomains to true. Then when you connect to your domain, instead of connecting to 192.168.0.40 you would connect to 192.168.0.40.xip.io

How do I load an HTTP URL with App Transport Security enabled in iOS 9?

See Apple’s Info.plist reference for full details (thanks @gnasher729).

You can add exceptions for specific domains in your Info.plist:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>testdomain.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <true/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSThirdPartyExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
            <true/>
            <key>NSThirdPartyExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSRequiresCertificateTransparency</key>
            <false/>
        </dict>
    </dict>
</dict>

All the keys for each excepted domain are optional. The speaker did not elaborate on any of the keys, but I think they’re all reasonably obvious.

(Source: WWDC 2015 session 703, “Privacy and Your App”, 30:18)

You can also ignore all app transport security restrictions with a single key, if your app has a good reason to do so:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

If your app does not have a good reason, you may risk rejection:

Setting NSAllowsArbitraryLoads to true will allow it to work, but Apple was very clear in that they intend to reject apps who use this flag without a specific reason. The main reason to use NSAllowsArbitraryLoads I can think of would be user created content (link sharing, custom web browser, etc). And in this case, Apple still expects you to include exceptions that enforce the ATS for the URLs you are in control of.

If you do need access to specific URLs that are not served over TLS 1.2, you need to write specific exceptions for those domains, not use NSAllowsArbitraryLoads set to yes. You can find more info in the NSURLSesssion WWDC session.

Please be careful in sharing the NSAllowsArbitraryLoads solution. It is not the recommended fix from Apple.

— kcharwood (thanks @marco-tolman)

Unable to connect react native app to backend on iOS 15

I managed to solve this, in case anyone came across this thread.
Weirdly, adding

'Accept-Language': 'en'

to the header when making the API calls solved this issue!

It is only happening on iOS 15 devices, so I don't know the reason, but it turned out to not be related to the HTTP connection.

---

Related Topics