I’m the owner of sofiaproduction.ru, a legitimate videography portfolio website. Safari on iPhone continues to display a red “Fraudulent Website Warning”. The warning is reproducible on multiple iPhones and networks. The website has no login, payments, downloads, deceptive redirects, or forms requesting personal or financial information. A technical audit found no malware, phishing content, credential collection, external scripts, or TLS/DNS problems. Google Safe Browsing currently classifies the domain as clean. I have already submitted multiple requests through Apple Website Review and filed Feedback Assistant report FB24432044 with a sysdiagnose captured immediately after reproducing the warning. Apple Support confirmed that phone support cannot handle Safari website-classification issues. A separate Security Research report was closed as out of scope without being routed to the responsible team. The warning remains. Could an Apple engineer please confirm the correct escalation path or help route FB24432044 to the team responsible for Safari Fraudulent Website Warning / Safe Browsing classification? I can provide any additional technical evidence required.

Hi , I have the DB 7 of Ios 27 on 17 Pro Max and Ipad Pro M5 . This alert appeared on my iPhone for the first time yesterday whilst I was reading an online article, and it reappeared this morning. On my iPad Pro, however, it doesn’t appear… I’m also running iOS 27, build 7, on my iPad Pro.

Hi! I currently have a web extension sucessfully published to Firefox. And now I'm trying to make the same web extension available for Safari. But I am having some trouble. Steps to reproduce this issue: Through appstoreconnect I create a new app. Within the app I select the tab Xcode Cloud, and scroll down to the Safari Web Extension Packager. When I try to upload a .zip file of my extension I get the error message: "NetworkError when attempting to fetch resource." According to the docs this upload feature should be compatible with any browser. I'm using Firefox version 154 running on Linux Mint 22.3. Note to forum admins: I originally tried to post this under subtopic Web Extensions but for some reason I kept getting an error when hitting "Post". That's why I'm posting this issue under the sub-topic General.

Using the official Apple Pay JS SDK (https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js), the onvalidatemerchant event returns the validationURL: https://apple-pay-gateway.apple.com/paymentservices/startSession Our server performs merchant validation via mTLS using exactly this URL, with a valid Merchant Identity Certificate, and Apple responds with HTTP 400 Bad Request. Apple's current documentation instead references /paymentservices/paymentSession and states that "Start Session is being phased out and replaced by Payment Session". Since the URL is provided by Apple's own SDK, is startSession still valid when returned by onvalidatemerchant, and why is it rejected with 400? Anyone is experiencing this?

I am creating passkeys using client side javascript and trying to see how the friendly name of the passkey is created. When the passkey gets created the publicKey the name for the relying party is ignored and iOS and MacOS retrieves the page of the relying party. It seems the Open Graph site_name meta tag is used for the friendly name. And the apple-touch-icon is the icon on iOS (but not on MacOS) in the passwords app and it needs to be over 180px. Is there anywhere this is documented and confirmed as once the passkey is enrolled updating the site_name or apple-touch-icon the image never gets updated.

Two unrelated, legitimate websites I own are both shown as "Deceptive Website — Apple has identified this website as fraudulent" in Safari (iOS + macOS), and even inside my installed PWA on iOS. This is a false positive and I can't find a working way to get Apple to remove it. Why I'm confident it's a false positive: Google Safe Browsing site status: clean Google Search Console (verified owner) > Security Issues: none Yandex Webmaster > Security: no violations VirusTotal: 0/92 detections Chrome, Firefox, Yandex Browser: NO warning on any platform Only Safari shows it, wording is "Apple has identified..." — i.e. Apple's own list, not the Google Safe Browsing feed The sites are genuinely benign: no brand impersonation, no third-party credential harvesting, no malware, no drive-by downloads. The interesting part — it's TWO unrelated sites: Site A: a small web app (SaaS with a login form) Site B: my personal developer portfolio — static, no login at all They share almost nothing: different codebase, different design, different hosting (Site A is behind Cloudflare with a Google Trust Services edge cert; Site B is a plain nginx box with a Let's Encrypt cert), different TLS issuers, different stacks. The ONLY common denominator is me as the owner/registrant (same person, same contact email, same registrar account). This makes me think the domains were clustered by registrant/owner rather than by anything on the sites themselves. The two-sites fact also rules out the usual scapegoats: it isn't Cloudflare (Site B isn't even on Cloudflare and is flagged too), nor the cert issuer, host, or stack, since those differ. What I've already done: Clicked "Report an error" on the Safari warning page Submitted the Google Safe Browsing incorrect-warning report Filed a tracked report in Feedback Assistant (FB number, status Open) Hardened both sites anyway: CSP + security headers, SPF/DKIM/DMARC, and real trust pages (About with owner identity + contact, Privacy Policy, Terms, linked from homepage and login page) It's been about a week with no response. My questions: When Google Safe Browsing is clean but Safari still flags, what feeds Apple's OWN fraudulent-site list? Is registrant/owner clustering a real mechanism here? Which removal channel actually works in practice? Realistic timeline for a false-positive removal? If one domain is cleared, does that clear the owner-level association for the other, or do I appeal each separately? Is there anything that re-triggers it? (Considering a domain migration as a last resort and want to avoid a new domain getting re-flagged.) Any first-hand experience is appreciated — the process is completely opaque.

My site formtracker.ru shows Safari's "Deceptive Website" warning. I believe it is a false positive, and I am trying to understand how the Apple-side check is reviewed, since every other signal I can measure is clean. What the site is A strength-training tracker that runs as a Telegram Mini App. There is no login form, no payment form, and no field anywhere that asks a visitor for credentials, card details or personal data — authentication happens inside Telegram, not on the page. The site does not imitate any brand or product; all content is our own. Privacy policy and terms are published at /privacy.html and /terms.html with a working contact address. What I verified Google Safe Browsing: clean VirusTotal: no detections Chrome, Firefox and other browsers on the same device: no warning The warning appears only in Safari One reproducible observation After migrating hosting I created a brand-new subdomain that had never been published, linked or crawled anywhere, pointing at the new IP. Safari flagged it immediately on first load. That strongly suggests the entry applies to the registrable domain and all of its subdomains rather than to a specific URL or IP — and therefore that nothing I change on my side (hosting, content, subdomain) can clear it. Possible contributing factor, already removed Until 19 Aug 2026 the site was hosted at 79.137.205.96. That address sits inside a range listed by Spamhaus SBL under a "bulletproof hosting" classification. The listing covers the whole /24 and the neighbouring /24s, including addresses unrelated to my service, so it was not specific to me; AbuseIPDB has zero reports for that address. I have since moved to a different provider entirely, and the current IP is clean in Spamhaus ZEN, Barracuda, SpamCop and SORBS. I am not claiming this was the cause — I have no way to know. It is simply the one negative signal I could find and verify, and it no longer applies. What I have already submitted "Report an Error" from the Safari warning screen The Fraudulent Website Warning review request form Feedback Assistant: FB24430497 One more detail The warning also appears with the device region set to Germany, so it does not appear to be region-specific. My questions Is there a review channel for the Apple-side list other than the three above, and is there any way to tell whether a submission was received at all? Since a never-published subdomain was flagged on first load, is the entry expected to apply to the whole registrable domain? If so, is a domain-level review the only path? Has anyone here had a Safari-only false positive cleared, and roughly how long did it take? I am happy to provide anything else that would help — full URLs, screenshots, timestamps.

Five of my sites are flagged by Safari's Deceptive Website Warning. They are legitimate and none of them collect credentials, imitate another brand or contain social engineering content: store-api.ru — paid access to third-party AI APIs (clearly states it is not affiliated with OpenAI, Anthropic or Google) cenwise.ru — price comparison service kirillportfolio.ru — personal developer portfolio (no login, no forms, no data collection at all) 3021.ru — habit tracking app animegenai.ru — AI image generation service All five are clean in Google Safe Browsing, Google Transparency Report, Google Search Console and Yandex Webmaster. Safari is the only place showing a warning. The flag appears to be inherited from a previous hosting provider whose IP ranges had reputation problems, and it seems attached to the domain names rather than to the current infrastructure. This is directly testable: On 20 July 2026 all sites were migrated to a new host — a single server, single IP (152.53.119.191). On that exact same server and IP, the domains created AFTER the migration are NOT flagged: filelama.com (live since 28 July, fully indexed), novelisstory.ru (25 July) and store-api.com (4 August). Only the domains that already existed under the previous host are still flagged. Same server, same IP, same certificates, same kind of content. The only variable is whether the domain existed before 20 July. store-api.ru and store-api.com are the clearest case: both are literally the same application behind the same nginx on the same IP, differing only in the domain name. The .ru is flagged, the .com is not. I submitted requests through websitereview.apple.com on 20 July and again on 11 August 2026. Neither produced a response or an acknowledgement, which as I understand is expected behaviour for that form. My questions: Is websitereview.apple.com still the correct — and only — channel for a site owner to dispute a false positive? Is there any way to confirm that a submission was received, or a typical review timeframe I should expect? Would a Feedback Assistant report under Safari add anything here, or would it simply duplicate the request?

Observed versions: Reproduced on Tahoe / Safari 26 and iOS 26 Safari. Not reproduced on v18 Safari. Not reproduced in Chrome with the same reduced test setup. We are seeing a Safari-only rendering issue affecting an ad creative inside an iframe on both desktop Safari and iOS Safari. What we observe: The issue is reproducible in Safari on OS X and iOS v26. We do not reproduce it in Chrome with the same test setup. We can reproduce it in a minimal test case, outside our site app code. The issue appears tied to the rendered iframe document/layout, not our outer page layout. The problematic rendered structure inside the iframe looks like this: <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script src="https://www.googletagservices.com/dcm/dcmads.js"></script> </ins> </div> Here is a simplified, local-reproducible version for testing: <div class="GoogleActiveViewInnerContainer" style="left:0px; top:0px; width:100%; height:100%; position:fixed; pointer-events:none; z-index:-9999;"></div> <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script> document.write( '<a target="_blank" href="#"><img ' + 'src="data:image/svg+xml;utf8,' + encodeURIComponent( '<svg xmlns="http://www.w3.org/2000/svg" width="320" height="50">' + '<rect width="320" height="50" fill="#ffd8d8"/>' + '<text x="160" y="30" text-anchor="middle" font-family="Arial" font-size="14" fill="#222">' + 'img placeholder' + '</text>' + '</svg>' ) + '" ' + ' alt="Advertisement" border="0" width="320" height="50" style="display:block" /></a>' ); </script> </ins> </div> In Safari, this produces extra vertical spacing / cutoff above the ad. In the test code you will only notice an added top spacing, but when rendered in a live ad, the bottom gets cut off. A few details that may help: If we manually change the inner ins.dcmads from display:inline-block to display:inline, or adding overflow:hidden, the spacing issue goes away. If the loader script is moved outside the ins during manual experimentation, the issue also goes away. This makes it look like a Safari layout/rendering issue involving an inline wrapper around an inline-block ad container during script-driven rendering. Questions: Is this a known Safari/WebKit layout issue involving inline + inline-block content in iframe documents? Has there been any recent Safari/WebKit change that could affect this rendering path? Is there a preferred reduced repro format for reporting layout issues like this?

When I login to an account on a subdomain of a main domain, I want to be able to store a separate password for the same login id on the main domain account. This doesn't seem possible in the current Safari implementation.eg: domain.com is the main domain and is the general information site.my.domain.com is the subdomain that hosts the customer support.I want different passwords on each for the same login ID... Can't I do this?--marcel

Hi, Looking for feedback from the community. We have a app that has a weather module and a subscription module. They are built in a table format. The weather module has Y and X scroll, however the subscription only has X scroll. When we test the app on an apple device using safari browser these modules moves around in all directions with touch method. The weather module should only move on X or Y scroll however with touch screen movement it moves it all directions, including the titles of the table columns. In regards to the subscription page in only has X scroll, however it has 2 scroll a top one after all the subscriptions are listed and then a bottom on after the total cost of all the subscriptions. The module behaves fine in windows and android devices, however it does not on safari. How do we address this issue? Any suggestion will be greatly appreciated. AJ

Is anyone else seeing Instagram fail to open App Store links tonight? Started for me a few hours ago, iOS only. To rule out my own setup I put a bare App Store URL straight in my bio, and I also tapped the App Store links on a few competitors' sites. Same result every time: nothing happens, no error, no page. Same phone, same moment: Safari works, Facebook and YouTube work, TikTok fails. Has Instagram started blocking store links the way TikTok does? If so, it looks like we're back to telling people to tap the ⋯ menu and "Open in external browser" before they can install anything.

I am implementing push notifications for a web application running as a PWA on iPad using Web Push. When sending a push notification to the web application, I received a 410 response from the server. I would like to understand the cause and reason for receiving this 410 response. The library used for sending push notifications is a commonly used JavaScript Web Push library. Could you please explain under what circumstances Apple Web Push endpoints return a 410 response, and whether this indicates that the existing push subscription is no longer valid and should be re‑registered.

My Iphone 17 Pro Max is in ioss 27 and it is having troubles with wifi issues, It works on celluar data but however when conected to wifi it only work son certain programs such as safari, it does not work on imsg, social media and app store. However everything works fine on data, I know its not a wifi problem as my Iphone 16 pro max is having zero issues with the wifi connected to it so I am not sure what the issue is

Although I have reduced my Mac's MTU to solve the MTU blackhole problem, Safari is quite slow if I enabled iCloud private relay (scenario 1). At the same time, Chrome functions normally. When I turns off iCloud private relay, the Safari's performance improves immediately. Packets captured by tcpdump at a LAN gateway (FreeBSD) shows iCloud private relay uses UDP protocol and doesn't fallback to TCP protocol. If the MTU blackhole is a problem, the connection will switch to TCP protocol, given prior tcpdump captures. I am waiting for macOS 27 Beta 5 but still no update released yet.

When using passkeys stored in iCloud Keychain (Passwords app) via Passkey Autofill in browsers other than Safari, the userVerification parameter is ignored and user verification (UV) is not performed. As a result, relying party servers that require userVerification = required fail validation because the UV flag is not set, causing passkey authentication to fail. This issue occurs when the following setting is disabled: Settings → Face ID & Passcode → Use Face ID For → Password AutoFill The issue is reproducible only with the following combination: Non-Safari browsers (e.g. Chrome) Passkeys stored in iCloud Keychain (Passwords app) Passkey Autofill The issue does not occur in the following cases: Safari with passkeys stored in any credential manager Non-Safari browsers using credential managers other than iCloud Keychain Steps to Reproduce: Go to Settings → General → Autofill & Passwords, and enable the Passwords app under “Autofill From”. Go to Settings → Face ID & Passcode → Use Face ID For, and disable “Password AutoFill”. Open Chrome and navigate to https://webauthn.io Enter a username and tap “Register” to create a passkey using the Passwords app (iCloud Keychain). On webauthn.io, go to Advanced Settings → Authentication Settings, and set “User Verification” to “Required”. Reload the page, tap the input field, and perform Passkey Autofill. User Verification is not triggered, and “Authentication failed” is displayed on webauthn.io. === This issue has already been reported via Feedback Assistant as FB21756948. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.

My domain vendezo.com is completely clean on Google Safe Browsing and VirusTotal, but Safari still shows a Deceptive Website Warning. Request through websitereview.apple.com was ignored. Please help

We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.

Hello Apple engineers and fellow developers, Over the past few weeks I have noticed multiple reports from different developers whose legitimate websites have been classified by Safari as “Fraudulent Website Warning”, despite passing every major public security and reputation check. My websites appear to be affected by the same issue. Domains https://skvoz.net https://skvoz.org Both domains were registered on July 15, 2026. The Fraudulent Website Warning first appeared on July 22, 2026, only one week after registration. Both websites are legitimate services operated by our team. Neither website impersonates another brand, attempts to collect Apple IDs, banking credentials, passwords, or any other sensitive information through deceptive means. Extensive verification performed After the warning appeared, we performed a comprehensive technical and security review. Website security ✅ No malware detected ✅ No phishing content ✅ No unauthorized redirects ✅ No suspicious JavaScript ✅ No mixed-content issues ✅ HTTPS configured correctly ✅ Valid TLS certificates Infrastructure DNS configuration verified SSL certificate chain verified using OpenSSL Server responds correctly over HTTP/2 IPv4 and IPv6 connectivity verified Origin server behaves correctly Cloudflare configuration was thoroughly tested during troubleshooting and ultimately removed from the production setup to eliminate it as a possible cause Reputation checks We verified both domains and the hosting IP address using multiple public reputation services. Results were consistently clean. This included services such as: Google Safe Browsing Google Search Console VirusTotal URLVoid IP reputation databases None of them currently report malware, phishing activity, or any other security issues. Apple-specific actions We have already: submitted a Website Review request; contacted Apple Security via reportphishing @apple.com requesting a manual review. At the time of writing, the warning is still present. One unusual observation One particularly unusual observation is that both of our domains (skvoz.net and skvoz.org) received the warning independently. These are separate domains serving different purposes, yet both appear to have been classified in the same way despite passing the same technical and reputation checks. This made me wonder whether Apple’s reputation system may evaluate related domains or shared infrastructure together. I understand the internal implementation is not public, but I wanted to mention this observation in case it is useful during investigation. Similar reports While investigating this issue, I found several recent reports from other developers describing almost identical behavior. The common pattern is remarkably consistent: Safari displays Fraudulent Website Warning Chrome, Firefox and Edge open the website normally Google Safe Browsing reports the domain as safe VirusTotal reports no malware Google Search Console reports no security issues valid HTTPS certificates relatively new domains no explanation regarding what triggered the warning This suggests the issue may not be isolated to a single website. Questions I would greatly appreciate any guidance from Apple engineers. Does Safari rely solely on Google Safe Browsing, or does Apple maintain an independent reputation database for Fraudulent Website Warning? If Apple maintains its own reputation system, are there any documented technical signals developers should verify? For example: redirects third-party scripts TLS configuration domain age hosting reputation infrastructure characteristics phishing heuristics machine-learning based classification Is there any recommended diagnostic process beyond Website Review? Approximately how long does a manual review usually take? Why I am posting This post is not only about my own websites. Over the past few months I have noticed an increasing number of developers reporting what appear to be false positive Fraudulent Website Warnings affecting legitimate websites. If there have been recent changes to Safari’s reputation or anti-phishing systems, it would be extremely helpful for developers to better understand what technical criteria should be reviewed before requesting reconsideration. Even if the exact detection logic cannot be disclosed, any general guidance on common causes of false positives would help developers resolve issues much more efficiently. Thank you very much for your time.