While reading MS SDL (Microsoft Security Development Lifecycle) presentations I found a recommendation to replace UDP with TCP in applications because TCP is more secure than UDP. But both of them are only transport layers, nothing more.

So why is TCP more secure than UDP?

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Dec 13, 2017 at 0:14

11 Answers 11


To send data to an application using TCP, you first have to establish a connection. Until the connection is established, packets only get to the OS layer, not the application. Establishing a connection requires that you receive packets back to the initiating end. If you wanted to forge an IP address not on your own network and establish a TCP connection, you'd need to be able to intercept the packets the other side sent out. (you need to be "in between" the endpoint, and where the packets to the forged IP address would normally go, or do some other clever routing tricks.)

UDP has no connection, so you can forge a packet with an arbitrary IP address and it should get to the application. You still won't get packets back unless you're in the right "place" of course. Whether this matters or not depends on the security you put in the application. If you were to trust certain IP addresses more than others inside the application, this may be a problem.

So in that sense, TCP is more "secure" than UDP. Depending on the application, this may or may not be relevant to security. In and of itself it's not a good reason to replace UDP with TCP since there's other tradeoffs involved between the two protocols.

  • "UDP has no connection, so you can forge a packet with an arbitrary IP address and it should get to the application." Should it? I was under the impression this is an urban myth due to egress/ingress filtering on the ISP side.
    – user541686
    Commented Jul 21, 2017 at 7:40
  • 14
    @Merhdad Nope. It's a major factor in the problem with DNS reflector DDoS attacks. Ingress filtering only means that the ISP checks if the packet's stated origin matches the interface/BGP neighbor it came in by, and egress filtering doesn't happen nearly as often as we'd like. Commented Jul 21, 2017 at 8:41
  • I agree with @Shadur, and with most of the answer, with the added commend that the "more secure" is not by design, but it soes offer quite some protection to spoofing, but it is not watertight. I would view it similar to e.g. NAT, neither are designed as a security feature, but it does add hurdles for attackers to have to jump over. Proper security would mean using an authentication feature in the UDP or TCP protocol, or add authentication headers (IPsec AH).
    – Cheatah
    Commented Jul 22, 2017 at 15:22
  • Anyway, one cannot just arbitrarily replace UDP with TPC. Delivery delays when packets are lost, lengthy connection setup, no multicast... UDP vs TCP choice is not about security, it's about application requirements.
    – spectras
    Commented Jul 22, 2017 at 23:59

Plain UDP does not keep state, have handshakes etc. This mean an attacker could easily send a spoofed packet unless there are protections at other layers.

On the other hand, sending a spoofed TCP packet requires the attacker to guess the sequence number and client's port of an established connection.

  • Or just to be in the same lan, and poisoning arp tables to get all the communications and then just increase the sequence when he want to insert a packet and this make a 'legit' packet become dropped as a bad retransmission...
    – Tensibai
    Commented Jul 20, 2017 at 14:54
  • 4
    Worth noting that any halfway secure app should be keeping state, implementing handshakes, etc., itself, so TCP's extra features should be redundant.
    – Nat
    Commented Jul 20, 2017 at 21:53
  • 1
    @Nat worth comparing wrapping TCP in TLS and not noticing higher levels of handshakes with reimplementing IKE to have a secure UDP interaction that can handle loss in the handshakes that should make things redundant.
    – lossleader
    Commented Jul 21, 2017 at 22:05

TCP isn’t more secure than UDP, it is more “reliable” as it is stateful and requires acknowledgment of each segment. UDP is stateless and just sends segments without knowing of the client gets them or not.

Neither have any bespoke security features that other doesn’t, differences are mealy down to the different requirements of each protocol, any perceived security benefits are mealy by-products of the protocols functionally rather than a deliberate security feature.

EDIT: UDP and TCP have specific uses, none of these uses relates to security.

Both protocols rely on other protocols to provide security. So although TCP may have a slightly smaller attack surface, this is really inconsequential as to secure either you require a security orientated protocol. Protocol such as DTLS or googles QUIC.

Choosing to implement TCP for a use case that is better suited for UDP, rather than securing UDP correctly (TCP would also require securing in most use cases), would be like using a 9 iron for putting because you think that a 9 iron would be a better weapon to defend yourself with in a fight...when you have a gun in your pocket.

  • 22
    Security by fortunate side effect is still security. It may not be great security, but it can still be more secure than another case.
    – Yakk
    Commented Jul 20, 2017 at 15:21
  • 10
    Yes I can see this point of view. But choosing TCP over UDP is making a design decision based on a side effect. Personally if I had a use case that would be better suited for UDP, I would use UDP and secure it with protocols that are designed for security. Commented Jul 20, 2017 at 15:28
  • 1
    Since integirty is by definition a pillar of security and the greater attack surface of UDP mainly consists of attacking integrity by spoofing packets then I guess its safe to say that TCP is more secure. Commented Jul 21, 2017 at 4:25
  • 6
    @PanosK. Integrity means that the data is trust worthy. The simple error detection in TCP does not provide this. It isnt supposed to and wasnt designd for it. Saying TCP is more secure than UDP is like saying a Volkswagen is a better family car than a Ford when you are talking about what is a better tank for warfare. Yes the Volkswagen may have a 5 star safety rating and the Ford only 4, but it still isnt a better tank and still isnt going to defend you in a tank fight. Commented Jul 21, 2017 at 5:15
  • 1
    Best explanation by far.
    – Overmind
    Commented Nov 16, 2017 at 9:51

Is TCP more secure than UDP?

Yes, but we have to be very clear about what we are talking about when we are talking about "security" and not generalize this statement to upper layer protocols.

Currently, security is often associated to the CIA triad:

  • Confidentiality.
  • Integrity.
  • Availability.

The version 4 of the IP protocol, which is still the most commonly used now, is a very old beast which was developed during the 70's and 80's.

At that time, confidentiality was not really a subject and what was really targeted was to achieve integrity and availability (the Arpanet network, the ancestor of the Internet which gave birth to the IP protocol, was designed to ensure a continuity of service even in the event of a nuclear war, not to protect in-transit data).

In this optic, two transport protocols were developed over the IP layer: TCP and UDP.

TCP was the one designed to ensure both the integrity and availability properties. It includes what was at that times advanced techniques such as a three-way handshake, parameters negotiation, various connection state handling, transparent packet reordering, acknowledgement windows and retry mechanisms. This brings good guaranties to the sender that the data it sent has been received in a complete an uncorrupted form (ie. no missing, altered or unordered parts).

Remind though that what this protocol was targeting was a technical disaster, not a malicious tampering of the data in transit. Such issue was completely out-of-scope at that time.

UDP on the contrary was designed to be a fast protocol. It has none of the above mentioned feature, and therefore none of their overhead too. In particular, when the sender sends some data using UDP, the data received may be incomplete, unordered or not received at all: the UDP protocol by itself does not provide any mechanism to prevent or detect this neither on the sender or receiver sides.

In this way, when focusing on the data integrity and availability properties of security, TCP is indeed more secure than UDP.

Is an application protocol relying on TCP more secure than one relying on UDP?

Certainly not.

This only means that people developing an application protocol relying on UDP will have more work since they may have to implement in their application protocol workarounds for the features missing in the UDP protocol. They will have to take into account that data sent may not be necessarily received, that data received may not be in the right order, etc. These are all well-known problems.

OpenVPN for instance, while it supports TCP mostly for compatibility with restrictive firewalls, runs by default and runs best over UDP. Switching it to TCP is possible but will not increase its security in any way as the difference between the two transport layer protocol UDP and TCP is fully handled by OpenVPN itself. Switching it to TCP will only add the TCP overhead to the OpenVPN protocol, thus reducing its performance.

Is TCP better than UDP?

No, this is entirely an application protocol design choice.

UDP is a more raw protocol. When used correctly and carefully it may achieve better performances than TCP at the price of a more difficult development and maintenance of the application protocol.

  • When the application is not time sensitive, TCP imposes itself as the natural choice as there is no need to reinvent the wheel.
  • When the application is time sensitive, a discussion must occur on which to choose knowing that each will come with its drawback: a potential performance penalty with TCP against a certainly more complex application with UDP.

Most protocols are not time sensitive and therefore TCP is most widely used protocol. Indeed, when you load a web page or receive an email, there is no difference if you receive it 10 milliseconds sooner or later.

Two classical examples of protocols using UDP, in addition to the OpenVPN previously cited, are media streaming and DNS.

With media streaming, you don't really care if one video frame or a few milliseconds of video or audio is missing, as long as the video or audio is playing smoothly and synchronously. In such case, you don't want to induce repetitive pauses because TCP detected a missing packet and asked the sender to resend the content of the last acknowledgement window.

With DNS, requests and answers are usually very short and you want the name resolution process to be as fast as possible (note that longer and less time-sensitive answers such as DNS zone transfers usually still occur on TCP). It is faster to resend the name resolution request to the DNS server on the very few times the request or its answer gets lost than processing a full-fledged three-way handshake for every request.

What about confidentiality and malicious sniffing/tampering (and IPv6)?

All we cared about until now was, in the spirit of this old IPv4, the balance between transmission speed and data integrity + availability. Now, if we want to add confidentiality on top of this, we can do this but it will have to be done at the application layer as, as stated before, IPv4 is not concerned by confidentiality issues.

A modern, full-fledged implementation of security can be implemented at the application layer and rely on either TCP or UDP (or both) protocols without any impact on the application protocol security itself (see the example of OpenVPN above).

However, as stated in the beginning, IPv4 really comes from a another computing age. It got a successor by the name if IPv6, which natively supports IPSec at the IP layer, thus providing more modern security services below transport protocols such as UDP and TCP.

This allows to delegate in-transit data encryption from the application to the network layer, and allows both UDP and TCP to provide exactly the same security guaranties. However, in most scenarios UDP performance gain will be counterbalanced by IPSec overhead, so I'm not sure there would be any advantage in using UDP instead TCP as long as IPv6 IPSec is being used.


Not really.

Neither protocol has any built-in features which are meant to provide confidentiality. Any security is supposed to be provided by the protocol layers above (or below).

TCP is a more complex protocol than UDP which makes it a tad bit harder to spoof, but these complications are rarely a serious obstacle.

When people say that TCP is "more reliable" than UDP, they don't refer to security. TCP is more reliable because it ensures that all segments are received in order and any lost segments are retransmitted. UDP does not guarantee this. When the connection is bad, UDP segments can get lost without a trace or arrive in the wrong order. How to deal with this problem is up to the application.

  • 2
    Could you please expand on the last paragraph? What exactly do you mean by "spoof"? As far as I know, TCP isn't not only a tad bit harder to spoof, it's actually a lot harder to spoof.. like really really harder.
    – Adi
    Commented Oct 8, 2014 at 12:41
  • @Adnan I would rather not like to expand on this because it's not really on-topic for this question anyway (spoofing is about violating integrity, not confidentiality). But you are free to open a new question when you are interested in this topic.
    – Philipp
    Commented Oct 8, 2014 at 12:44
  • 1
    Oh, I'm sorry. Perhaps I wasn't clear. I was politely saying that you're last paragraph is poorly worded, of low quality, and possibly stating incorrect information (unless you elaborate). I wasn't asking for extra info, I was telling you to fix your answer (in case it's wrong, which is only clear if you elaborate what you mean by spoofing).
    – Adi
    Commented Oct 8, 2014 at 12:45
  • As far as I know, and please correct me if I'm wrong, once you talk about TCP/UDP and spoofing, then it's automatically assumed you're talking about making a connection (in case of TCP) appear to be coming from a source that isn't the real source. Unless of course you mean the network engineering process Protocol Spoofing en.wikipedia.org/wiki/Protocol_spoofing#TCP_spoofing (and I don't think you're talking about that)
    – Adi
    Commented Oct 8, 2014 at 12:48
  • 1
    oh, looks like I'm not the only confused by the poorly worded paragraph, security.stackexchange.com/questions/69181/what-is-tcp-spoofing
    – Adi
    Commented Oct 8, 2014 at 12:50

TCP is "Connection-Based" which means it has reliability built in, in the form of sequence numbers. So, for example, I send you an image over TCP but, 1/4 of the packets get dropped. Since we have a connection based protocol with sequence numbers, your computer will know that you are missing that data and therefore request that data from me in order to have data integrity. This is slower but, much more secure. Also, in order to spoof TCP/IP packets, you have to catch that sequence number and send a malicious packet. Without a man in the middle, that is almost impossible!

UDP is a "Connetionless" protocol, meaning it just sends the data and forgets. There is no data reliability or integrity, but it's faster and more efficient for some applications.

  • That not impossible to flood a machine with tcp syn/ack/syn-ack packets... interception is harder, but the sequence is guessable by sniffing after an arp poisoning for exemple (not on internet, but on local network of one the parties). So there's no real added security per se.
    – Tensibai
    Commented Jul 20, 2017 at 14:51
  • I would still consider it more secure as the steps to compromise TCP, which holds more valuable data, is more difficult and cumbersome. Essentially, you need to compromise a network, set-up an MiTM by ARP poisoning and subsequently (maybe) DNS poisoning, and from there be able to inject whatever as all traffic is running through you, "The fake gateway". Or you could just set-up a fake AP and wait for people to connect which is much easier haha. Either way, TCP hijacking = hacking with more steps whereas UDP Hijacking = hacking. lol Commented Jul 20, 2017 at 15:21
  • if the goal is to send a packet on behalf of the original user, then you just have to respond to arp request of the gateway on the user side, or of the destination server on the server side to get a copy of the packets to guess the sequence number. That's just one step more than udp. If you wish bi directional, yes you have to get as MITM, but that's also true for UDP. The added security is very small
    – Tensibai
    Commented Jul 20, 2017 at 15:27

In practice, TCP is easier to police in a firewalled network: Traffic pertaining to externally vs internally established connections, and thus client vs server roles, can be clearly distinguished and handled by separate policy. For example, you can trivially ensure hosts on a protected network can access an external web server but will not be able to act as a web server to outside clients. For UDP services (for example DNS), enforcing such policies requires far more intelligence and guesswork, since you have to take information above and below the transport layer into account.


TCP is not "more secure" than UDP:

  • TCP has no encryption feature per se;
  • TCP packet transmission is reliable, but you can emulate the same over UDP.

UDP is just a thin layer on top of the IP packets, whereas TCP has complex - and standard - additional mechanisms, which are part of the Operating Systems.

Worth taking a look at the QUIC project, to find out more about TCP/UDP differences, and why Google did create its own secured HTTP/2 transport layer over UDP instead of TCP.

Let's quote https://www.chromium.org/quic :

Key advantages of QUIC over TCP+TLS+HTTP2 include:

  • Connection establishment latency
  • Improved congestion control
  • Multiplexing without head-of-line blocking
  • Forward error correction
  • Connection migration

Let's set some pros/cons from security prospective for each and see:


  • (+) Relatively difficult to scan UDP open ports, and no stealthy scan exists (half connection in TCP by sending SYN).
  • (-) Network devices (e.g. stateful firewalls, NAT) struggle to control UDP connections, as there are no FLAGS to rely on.
  • (-) Reflected attacks are more common due to the absence of connection.
  • (-) Spoofing IP is easy, and used in DoS attack.


  • (-) Stealthy scan can detect open TCP ports (send SYN only to detect open ports)
  • (+) Network devices (e.g. stateful firewalls) can easily track and control TCP connections.
  • (+) Forging packets is not easy, as it requires to provide the correct `Sequence number and acknowledgement number.
  • (+) Not as easy as UDP to spoof the IP because of the initial handshake.

TCP has a concept of a connection, UDP doesn’t. However the connection concept is both a strength and weakness from a security standpoint. The main security strength of the connection is that it is standardized, the application developer, networking gear and firewalls can all rely on a fixed method for, establishing the connection, handling packet fragmentation, retransmission and so on. Additionally the connection concept makes it easier to build additional layers of security on top, for example SSL.

However a TCP connection doesn’t provide much protection from an attack that directly targets the transport layer, for example a SYN flood attack. With UDP you could theoretically authenticate every single packet to mitigate some of these risks.

Therefore I would argue that UDP is “theoretically” more secure than TCP, however we live in a world where security is not perfect, so theoretical strength is somewhat meaningless. In the real world it is possible to find examples both ways - where one protocol has failed in a way that the other would not have been vulnerable to.

In summary, I don’t think there is an answer to which protocol is more “secure” you need to qualify your question with what threats you are concerned about and how much and how long you are willing to spend to mitigate them. If it’s all threats and you have an infinite about of time and money, then my theoretical answer holds.

  • 2
    UDP has flooding attacks too. Your answer needs more support as to why UDP is "theoretically" more secure than TCP. Commented Jul 23, 2017 at 1:18
  • @user2320464 The rfc792 hole can be closed by never sending the “destination unreachable” packet. There are also many asymmetric attacks against UDP based services; but I am simply bucketing these as, flaw in the application (or the protocol the application implements, DNS, ntp, … etc). I have sighed a problem with TCP (the need to allocate resources after receiving the first packet). Please sight any protocol level (non application specific and non implementation specific) flaw in UDP, that doesn’t also apply to TCP and that couldn’t be closed in our theoretical world. Commented Jul 24, 2017 at 19:26

Currently, TCP is not more secure than UDP. TCP is more reliable than UDP because TCP can detect and retransmit error packets.

If one wishes to have secure data transmission, then you are looking at using some format encryption such as TLS or IPSec.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .