Activity Forums Salesforce® Discussions What are the primary security issues with web services in Salesforce?

  • Sanjana

    Member
    July 13, 2018 at 1:21 pm

    Hello Suniti

    To ensure reliable transactions and secure confidential information, web services requires very high level of security which can be only achieved through Entrust Secure Transaction Platform. Security issues for web services are broadly divided into three sections as described below

    1. Confidentiality: A single web service can have multiple applications and their service path contains a potential weak link at its nodes. Whenever messages or say XML requests are sent by the client along with the service path to the server, they must be encrypted. Thus, maintaining the confidentiality of the communication is a must.
    2. Authentication: Authentication is basically performed to verify the identity of the users as well as ensuring that the user using the web service has the right to use or not? Authentication is also done to track user’s activity.
    3. Network Security: This is a serious issue which requires tools to filter web service traffic.
  • Parul

    Member
    September 15, 2018 at 5:14 am

    Confidentiality, Authentication, Network Security are the primary security issues with web services.

     

    thanks

  • shariq

    Member
    September 15, 2018 at 9:34 pm

    Hi,

    To add more -

    Disadvantages

    • Although the simplicity of Web services is an advantage in some respects, it can also be a hindrance. Web services use plain text protocols that use a fairly verbose method to identify data. This means that Web service requests are larger than requests encoded with a binary protocol. The extra size is really only an issue over low-speed connections, or over extremely busy connections.
    • Although HTTP and HTTPS (the core Web protocols) are simple, they weren't really meant for long-term sessions. Typically, a browser makes an HTTP connection, requests a Web page and maybe some images, and then disconnects. In a typical CORBA or RMI environment, a client connects to the server and might stay connected for an extended period of time. The server may periodically send data back to the client. This kind of interaction is difficult with Web services, and you need to do a little extra work to make up for what HTTP doesn't do for you.
    • The problem with HTTP and HTTPS when it comes to Web services is that these protocols are "stateless"—the interaction between the server and client is typically brief and when there is no data being exchanged, the server and client have no knowledge of each other. More specifically, if a client makes a request to the server, receives some information, and then immediately crashes due to a power outage, the server never knows that the client is no longer active. The server needs a way to keep track of what a client is doing and also to determine when a client is no longer active.
    • Typically, a server sends some kind of session identification to the client when the client first accesses the server. The client then uses this identification when it makes further requests to the server. This enables the server to recall any information it has about the client. A server must usually rely on a timeout mechanism to determine that a client is no longer active. If a server doesn't receive a request from a client after a predetermined amount of time, it assumes that the client is inactive and removes any client information it was keeping. This extra overhead means more work for Web service developers.

    Hope this helps.

  • Aman

    Member
    September 29, 2018 at 4:35 pm

    Hi,

    1. Data creation: You should make sure to use a good random source with enough entropy to generate these tokens.

    2. Data at rest on salesforce servers: You should use protected custom settings within a managed package. This allow access to your tokens only from apex code that is within your managed package.

    3. Data at rest on your servers: You should use standard mechanisms to protect passwords. For example, use SHA256 to hash the password with a strong and unique salt per user, and store the output only on a DB.

    4. Data in transit: You should make sure to use proper encryption and authentication for the outbound call from salesforce to your servers.

    Thanks.

Log In to reply.

Popular Salesforce Blogs