Has anyone worked through the reasoning that if I have a single-page application (SPA) whose HTML and JavaScript are hosted on Server X, sending credit cards to a remote API hosted on Server Y, does Server X fall under the scope of PCI?
Server Y in this scenario is PCI compliant (hosted application certified by the vendor via a 3rd party).
Server X does serve web pages over HTTPS, the SPA accesses Y's API over HTTPS, and we do make all reasonable efforts to keep X secure.
The API never returns card information, just masked "display" version of the card (i.e. "****" + last 4).
I've found one similar question, but the answer is over 10 years old at this point, and I know the PCI specifications do change of time.
If the credit card information never passes through Server X, as per your comments above, then server X does not need to be PCI compliant. PCI compliance only applies to software and networks that handle credit card information. Since that information is never on Server X, Server X is never within PCI scope.
Yes, Server X is in scope for PCI. If Server X is serving up the HTML/JS code that handles collection of PAN data, a vulnerability there could lead to leakage of data upon input.
If Server X was delivering HTML/JS but then the DOM was pulling in remote javascript from an external processor like Stripe to handle the UI components that collect PAN data, then Server X would not be in scope for PCI. However the organization would still be responsible for PCI self-assessment questionnaire level A -- "Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. "
Related
We have a requirement to call other APIs other than graph(like Dynamics, Power Automate etc.,) from our Add-in. All examples in Office Add-in Samples suggest to use bootstrap token and then exchange it to get tokens for subsequent APIs and make calls on the server. This forces all communication from our Add-in to be proxied via our server. This can be a unncessary performance bottle-neck. Can we not send the OBO tokens back to our client side Add-in and call other services directly from the client? Is there a known security issue with this approach?
The "received wisdom" about whether access tokens should be sent to clients or stored on clients has fluctuated over the last 10 -15 years, but in recent years the pendulum has swung pretty decisively to the idea that access tokens should not be on the clients. Client-to-server communication is much more vulnerable than server-to-server communication, because there are a wide variety of well-known ways to attack clients and trick users. At the same time, bad actors don't know when server-to-server communication is going to take place and it is much harder to get access to the server computers on either end of the communication.
There's a way from Codename One to provide access to Near Field Communication (NFC) ?
Anything new, out this post codename-one-nfc-beacon?
NFC is an Android only API and even there the availability in devices is "problematic". In iOS it's restricted to payment so there is no access to the underlying hardware. So there is no point in supporting the API in a framework that is designed for cross platform. I'm sure you can create a cn1lib similar to the fingerprint reader API or the SMS intercept API.
There are many companies which provides sim card hosting services for receiving sms, I wanna how is this possible (at the core level)? do they use any kinda protocol or any custom devices for forwarding text messages to there servers.
This depends on the type of SIM card hosting being offered, if it is Virtual SIM card hosting (VSIM) such as this https://www.world-text.com/services/virtual-sim-hosting/ then this is only achievable were the provider has a direct connection to a mobile network over SS7. This requires very specialist knowledge, software and hardware, but is a very reliable and fast option.
If however they are offering GSM modem based SIM card hosting such as this http://world-text.com/services/sim-hosting/ then this utilises GSM modems which are normally hosted in a data centre and communicated with over IP, with messages returned to the providers SMSC. This method is slower, and is of course reliant on a local cell tower signal to work.
Can one say an architecture using websocket technology is based on client-server model?
By definition The client–server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.
However using the websocket technology, two endpoints can both act as providers of a resource or service and also service requesters.
Say for example in a situation where the two endpoints are: a user device with a gps sensor and a computer machine, both connected in the network using websocket. And the computer machine is sending requests to obtain the current position of the user device (here the user device is acting as a resource provider and the computer machine as a requester). Later on the user device uses the websocket connection to request all its positions on the last 5 days to the computer machine (now the user device is acting as the requester and the computer machine as the resource provider).
If both devices can act as resource provider and requester, are they complying with the client-server model definition or not?
No it's not breaking anything. End Points are not devices they are connections between devices.
ie if we were asking each other questions and answering them
There would two connections between two 'devices' giving four endpoints. You to me and me to you. No conflict.
TCP is full duplex capable, and particularly WebSockets are full duplex. As #Tony Hopkinson pointed out, there is no conflict at all. This means, you can write and read at the same time.
WebSockets are push technology, more suited for events; while usual request-response models are pull technology.
You can have both client-server or peer to peer architectures with push approach, but pull is the normal choice for pull architectures.
Peer-to-peer Architecture: A peer-to-peer network is designed
around the notion of equal peer nodes simultaneously functioning as
both "clients" and "servers" to the other nodes on the network. This
model of network arrangement differs from the client–server model
where communication is usually to and from a central server. A typical
example of a file transfer that uses the client-server model is the
File Transfer Protocol (FTP) service in which the client and server
programs are distinct: the clients initiate the transfer, and the
servers satisfy these requests.
You can also provide a mix of peer-to-peer and client-server. For example, you can do requests via WebSocket, and at the same time, the server could send updates on its own initiative. I don't understand what you mean with "breaking the model". WebSocket is just a communication channel. In your app both models can coexists and use the same communication channel.
We're building a set of external web services to be consumed client-side (using jquery/AJAX) by visitors to our site. The web services need to be publicly available but we'd like to limit access to site visitors.
Importantly, the site in question sits behind a CDN and we cache page content for 24 hours; AJAX requests would preferably be cached as well but I'm conscious doing so will limit our authentication options. Our visitors access the site and services anonymously.
What are some standard "patterns" for authenticating client requests? I'm not dealing with confidential data per-se but do want to deter other users/sites from hijacking these services for liability (think data distribution) and performance reasons.
I'm thinking of a shared secret that's refreshed daily and used site-wide by all clients; any web service request would include the secret. Pretty basic but are there other, better ways for the service to detect the caller's origin in a manner that can't be spoofed?
If the threat to your web service is related to someone automating the client calls, you can implement rate limiting on server side. As you rightly mentioned, client can be required to provide key for each request. Alternatively, if only mortals are going to interact with web service, you can also implement Human Interaction Proof like Captcha etc. One thing to make sure is that "key" which will be used by client needs to given in controlled manner. I once came across a system which basically gave away unlimited keys - this means that automation control will be ineffective as an attacker can request as many keys and make unlimited calls. If you are limiting using IP address, make sure that you throttle requests on network part of ip address (A.B.C.X) as host part (X) can change (when users are behind proxies) If your clients are anonymous, the best/closest "identifier" is indeed address.